Benefits of using HTTP?

[aidv]

Hey.

I have been working on a project for quite some time now and up until now I haven't had the requirement to send very large data such as a long string, except of a few cases which I solved by sending the data and a specific long string in chunks rather than all at once.

My approach consists of sending a chunk to the client, and then send an acknowledge command back to the server wich then sends the next chunk etc etc until the whole data stream is sent.

Now I realize that it would be very nice to be able to send and receive unlimited length of data rather than sending them in chunks in some cases.

For example when I send a long command to the client, I need to send it in chunks even if my first chunk is 3000 bytes and the next chunk is 1 byte, which by definition isn't my problem, it's just that the extra amount of work needed to do it is unnecessary in my opinion.

I am suspecting that HTTP could handle this for me.

Are my suspicions correct?

What other options are there?

[derek.john.evans]

HTTP wont solve your problems if you have connection issues, but it should be used for all communications.

[aidv]

HTTP wont solve your problems if you have connection issues, but it should be used for all communications.

Could you elaborate "connection issues"?

I don't have connection issues.

I have coding "issues". not really issues, but yeah....

[taazz]

Hey.

I have been working on a project for quite some time now and up until now I haven't had the requirement to send very large data such as a long string, except of a few cases which I solved by sending the data and a specific long string in chunks rather than all at once.

My approach consists of sending a chunk to the client, and then send an acknowledge command back to the server wich then sends the next chunk etc etc until the whole data stream is sent.

Don't bother that is taken care for you on tcp level.

Now I realize that it would be very nice to be able to send and receive unlimited length of data rather than sending them in chunks in some cases.

Well any tcp based application can do that just make sure that you add some kind of end of transmission character at the end or a transmision size at the start and keep on sending and reading until the all data have been transmitted.

For example when I send a long command to the client, I need to send it in chunks even if my first chunk is 3000 bytes and the next chunk is 1 byte, which by definition isn't my problem, it's just that the extra amount of work needed to do it is unnecessary in my opinion.

I am suspecting that HTTP could handle this for me.

I don't know, although HTTP will open other doors for you (eg firewall doors) I wouldn't even go anywhere over tcp at this stage.

[derek.john.evans]

HTTP wont solve your problems if you have connection issues, but it should be used for all communications.

Could you elaborate "connection issues"?
I don't have connection issues.
I have coding "issues". not really issues, but yeah....

I guess, I assumed if you cant send large amounts of data, then there is a connection issue. What sizes are you talking about?

I like HTTP because its a no brainer. ie: There are many HTTP libraries, and how can you not like sending data with one command?

**EDIT**
On a "debatable" topic. The only issue I have with HTTP is its name. "Hypertext Transfer Protocol". It somehow implies HTTP is only for HTML, and anything else is not well suited to HTTP.

Ive seen that one issue causing programmers to design there own protocol which is nothing more than re-inventing the wheel.

I was on a project where HTTP was not chosen for 3 reasons:

1) HTTP is not suited for XML (incorrect)
2) The HTTP package size is large. (incorrect)
3) HTTP is stateless (correct, but a stateless design handles broken connections)

Basically, a lot of code was written which didn't have to be written, which caused a lot a bugs, and made the entire system brittle. ie: A minor glitch in TCP caused components to stop working, which required them to go though an elaborate logon procedure.

It was all really stupid IMHO, and was a total head case to debug. All because HTTP has a slightly incorrect name.

Plus! on top of all of that, they somehow wanted a system where companies could write their own components in other languages, assuming they first implement a custom protocol, even though every language already has HTTP client/servers.

Crazy! But, that's what they did, and it wasn't long before the company was closed and moved off shore, and everyone was out of a job.

Soo, why HTTP? Its easy, portable, well documented and it works.

[aidv]

Sorry, I never mentioned that I am using LNet for my communication over TCP.

Maybe LNet can't handle large data?

Ive seen that one issue causing programmers to design there own protocol which is nothing more than re-inventing the wheel.

That's exactly what I seem to be doing, and I don't want that. Just too much unnecessary work.

And we are talking about data of varying size.

Some data are simple commands with less than 256 bytes, and some data can be files of several gigabytes.

When it comes to large files, I prefer my current approach where the two devices communicate in chunks because of obvious RAM performance reasons.

But when it comes to commands I need a reliable way of sending long strings, maybe up to 2 megabytes or more.

So in short: I feel like I need a better way of sending and receiving strings, but for actual files, my current approach is good.