Hello,
Not sure if this is the correct place to post this as it kind of fits everywhere! lol
Anyway, we are designing a new piece of hardware that will send messages to our server. The question I have is whether we send the messages vie http to a PHP page or use sockets - possibly having a php listening socket. I am trying to find information on which way is the best way to go - all I can find are some sockets tutorials but these don't really answer the question as to which is best.
The problem we are anticipating the the volume - the messages are very small 9 bytes on average but there will eventually be many of them. They cold grow to 6000 a minute. We don't want to put a strain on the web server by receiving all these messages and at the same time serving web pages to the clients. Also we are being charged a network charge for bandwidth.
My thinking that the packages sent on Http would be larger due to the header information? But has anyone got any idea how much larger? Can anyone think of any dire reasons not to go with a socket approach?
We are running a LAMP server on Cent OS.
Many thanks
Scott Bailey
sockets vs http
Moderator: General Moderators
Re: sockets vs http
agravayne wrote:My thinking that the packages sent on Http would be larger due to the header information?
Correct.
Here I will assume you're opening new connection for every message you send. If it's not the case (i.e. you may send multiple messages per session) you will need to adjust this calculations accordingly.agravayne wrote:But has anyone got any idea how much larger?
Theoretically it depends on MTU of a network, over which you're connecting to the server. Normally there will be 3 packets sent to establish a connection (counting in both directions), 1 packet sent to server containing the request data, 1 packet sent from server to acknowledge it has received the data and 4 packets sent (counting in both directions) to close the connection. TCP has a header size of 20 (or 24, if there are Options field specified) bytes, IPv4 adds another 20 (or 24) bytes. Thus any successful TCP/IP session has a minimum traffic of 320 bytes. Application level protocols add their overhead on top of that. HTTP adds another roundtrip from server to client (server sends a response and client has to ack it), plus actual protocol overhead. Minimal HTTP request would look like this:
Code: Select all
GET / HTTP/0.9\r\f\r\f
Code: Select all
HTTP/0.9 200 OK\r\f\r\f
If message loss is acceptable, I'd suggest using UDP, which has much lower overhead. TCP connection has a significant overhead on itself, regardless of whether you use HTTP or not.agravayne wrote:Can anyone think of any dire reasons not to go with a socket approach?
Re: sockets vs http
Usually we are dealing with HTTP 1.1 and minimal request will add Host: header to this 
My opinion: if there is no reason not to use sockets, that just use sockets. Implementing custom protocols of course have disadvantages, especially if the protocol should be open for third-party developers
My opinion: if there is no reason not to use sockets, that just use sockets. Implementing custom protocols of course have disadvantages, especially if the protocol should be open for third-party developers
Re: sockets vs http
And I forgot Ethernet frame header + frame crc, which adds another 18 bytes (in case of DIX frames) to every packet.Darhazer wrote:Usually we are dealing with HTTP 1.1 and minimal request will add Host: header to this