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/.