From: Brian Candler Date: 2010-02-15T06:41:03+09:00 Subject: Re: how to detect used protocol (SOAP, JSON, XML etc.) jeljer te Wies wrote: > "For example, you wouldn't be able > to send multiple messages over the same connection, because the only way > the endpoint would be able to determine that the message had finished > would be waiting for the socket to close (*)." > > This is not true. you could initiate a special protocol. for example: > the sender first sends the amount of traffic it wants to send (just in > integer) so the receiver knows what he can expect. so for example: > - 51 > - {"server":"menus", "method":"deleteItem", "id":"2"} Then you're not just squirting the object over a raw TCP socket; you're adding your own proprietary encapsulation/framing protocol around it. And if you're going to do that, you might as well add another field which says whether it's JSON or XML or whatever, and hence the problem is solved. In this case, ultimately you're re-inventing HTTP. HTTP is admittedly an extremely complex protocol to implement correctly. For an example of what you need to do it right, see http://webmachine.basho.com/diagram.html So you may be justified in your own app by doing something much simpler. But first do a bit of research to see if some existing protocol might work for you (e.g. XML-RPC, JSON-RPC, XMPP) as it would let you use existing client code. > I know that if (for example a web browser needs more requests it has to > initiate a new connection for every request). No, it doesn't. With HTTP/1.1 the client can hold open a single TCP connection and send a series of requests one after the other. See RFC 2616 for more details. > Thanxs Brian! I am doing this research/building for my final thesis (on > my own) and I am building the prototype in RUBY (and then build the real > thing in C/C++ (beceause in Ruby it wil be SLLOOOOWW)) :P. It won't necessarily be SLLOOOWW; it depends what you're doing. If you're using HTTP, you can use one of the many excellent HTTP servers (e.g. mongrel, unicorn, rainbow to name a few), which contain C for the most important code paths; or something like Phusion Passenger under Apache or Nginx, which is basically an Apache module for running a Ruby Rack app. (Rack is the pluggable way to write a fast low-level HTTP service in Ruby) Then it depends how much actual request processing is required. In the best case, if you're just picking one of a few canned responses and sending it back, your ruby app could be almost as fast as a C one. If you do want to write a performant TCP server in a real high level language, you might also want to look at erlang. For example, ejabberd scales to tens of thousands of concurrent connections. Regards, Brian. -- Posted via http://www.ruby-forum.com/.