Topic: sockets vs http

[agravayne]

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

[nadeemshafi9]

we have a system that we deploy and other ysstems use that system from client locations, now these systems contact the server using a socket connection .

i have been thinking about why and without any research this is why i reckon,

1, http requires web server wich is unstable, a socket server that you have created will be there only for one reason and thats to listen for your device, nothing else will use it, you can send each char of your message start message and end one by one with a checksum to make sure the data is solid. there is little chance of teh server falling and if it does it wont affect your web server.

you can monitor it in your script what comes throgh etc etc.

HTTP is a protocol that runs on a socket, and a socket is what is used to
transport data between systems. If you want to run your *own* protocol,
create a new socket (TCP or UDP) using an *unused* port (e.g. 1001), and
then send *your* protocol down it!

basicaly creating your own socket the application is more pure no web server stuff less to fail

http has its own protocol used in socket communication http is a protocol socket is a loop running on your server listening to a port.

you dont need teh http protocol, i think you get the idea

you can use a filename.php with a socket

so if you communicate to filename.php  you can comunicate with it on multiple sockets

filename.php:1000

filename.php:2000

etc

but teh code inside the file will be listening for whatever port and teh data posted to it


read this

http://bytes.com/groups/net-vb/367435-sockets-vs-http

[nadeemshafi9]

this is a good exp

Hi there,

I "socket" simply connects two systems together, an IP address is the
address of the machine over an IP based network. If you connect 2 systems
together using TCP, that is known as a TCP socket, a socket requires a port
and an IP address to attempt to make a connection.

A "protocol" is a strict set of rules for transmitting specific types of
data for set purposes. For example IP based games used bespoke protocols
for speed, AOL IM uses it's own bespoke protocol to create an instant
messaging service, SMTP is a protocol used for sending emails. It's kind of
like a "language" designed for a specific purpose.

A protocols should only interfer with a firewall if the firewall is
either

A) Blocking the port from being used.
B) Sniffing the packets and making assumptions and presumptions,
causing consequentions and making aspertions... and other shuns that
firewalls have a habbit of doing.

But if you tell your firewall to allow connects on a particular port for
a particular application it should *not* give 2 hoots about what is being
sent backwards and forwards because it would not even be able to understand
it! A firewall can analyze recognized protocols for malicious code, such as
HTTP, SMTP or POP3 but not your own bespoke protocol.

TCP and UDP are *low level* protocols used by the network adapter to
transmit data over IP based networks. And yes you are correct, UDP does not
contain fail safe measures; like TCP.

But using HTTP as a protocol in your application would be absurd unless
you are making a web server. It is by far easier to make your *own*
protocol, believe me this is *not* hard, I'm actually making a set of
classes for VB.NET at the moment which make designing your own protocol a
piece of cake. Get into Netlinx, AMX and Crestron then you will understand
all about protocols, including how to rip them off.

Nick.

the jist of it is that you can limit communication on your system to only that port

[agravayne]

Many thanks for all this. does anyone know a resource for comparing packet sizes? We will be sending very small messages - approx 9bytes so we want to use the most efficient way. From what I understand a HTTP packet will be around 300 bytes before there is any data - thus our reasoning is to use sockets. Does anyone know the rough size of a standard TCP/IP packet in comparison and a UDP packet?

[thorpe]

http requires web server wich is unstable

Seriously nadeemshafi9, have you any idea what you are talking about?

basicaly creating your own socket the application is more pure no web server stuff less to fail

What?

http has its own protocol used in socket communication http is a protocol socket is a loop running on your server listening to a port.

you dont need teh http protocol, i think you get the idea

Network protocols exist to aid in the validation of data. If you build your own sockets server, you are still going to need to create your own or use an existing protocol to guarantee your client and server speak the same language.

Now, having said that. If you don't need the overhead of http, creating your own protocol (rules) could be the way to go for simple communication.

Probably a more important determining factor when choosing between tcp and udp is whether or not your client need to be notified of the data being successfully received by the server. udp is stateless while tcp holds a connection open between client and server.

[agravayne]

We will need to send back confirmation of the message being deleivered. ON top of that we may also want to end new instructions to the client in order to reprogram it.

I understand this can be done with UDP on the application side - just trying to weigh up if the saving in overhead is worth it.

[thorpe]

If I where in your shoes I'd likely setup something like lighthttpd to run on a different port to http and use it. Theres really not much point re-inventing the wheel, when http is there and is a very simple protocol to program for.

[agravayne]

Except that we are getting charged per 100k of bandwidth and will have 6000 messages per minute so we want to keep the overhead as low as possible to keep costs down.

What's the overhead for lighthttpd

[thorpe]

There is no extra overhead for lighthttpd, its just another http server like apache. Just thought it might be an idea if you wanted to use a separate server to your main web server.

[nadeemshafi9]

thanks for clearing it up for me too i wasent that far off.