agravayne Posted June 30, 2009 Share Posted June 30, 2009 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 Quote Link to comment Share on other sites More sharing options...
nadeemshafi9 Posted June 30, 2009 Share Posted June 30, 2009 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 Quote Link to comment Share on other sites More sharing options...
nadeemshafi9 Posted June 30, 2009 Share Posted June 30, 2009 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 Quote Link to comment Share on other sites More sharing options...
agravayne Posted July 7, 2009 Author Share Posted July 7, 2009 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? Quote Link to comment Share on other sites More sharing options...
trq Posted July 7, 2009 Share Posted July 7, 2009 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. Quote Link to comment Share on other sites More sharing options...
agravayne Posted July 7, 2009 Author Share Posted July 7, 2009 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. Quote Link to comment Share on other sites More sharing options...
trq Posted July 7, 2009 Share Posted July 7, 2009 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. Quote Link to comment Share on other sites More sharing options...
agravayne Posted July 7, 2009 Author Share Posted July 7, 2009 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 Quote Link to comment Share on other sites More sharing options...
trq Posted July 7, 2009 Share Posted July 7, 2009 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. Quote Link to comment Share on other sites More sharing options...
nadeemshafi9 Posted July 7, 2009 Share Posted July 7, 2009 thanks for clearing it up for me too i wasent that far off. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.