Vote for the best protocol for the given scenario

Question

I have a design decision to make. I need your advice.

Requirements:

• A server and a client. client is typically a mobile phone.
• Connected through t

Answer 1

I'd recommend option 3, and don't worry about the threading issues. If you are hosting this in a servlet container, the container will almost certainly make use of thread pools to optimize the processing of incoming requests and control the number of threads in the application.

Also HTTP/1.1 supports pipeline and reuse of connections for subsequent requests. This reduces the burden on the server for setting up and tearing down connections.

Answer 2

For starters, avoid SOAP if you want to put the client on a mobile phone and have a light solution. SOAP is a pig on wasting CPU and bandwidth. It is not the simplest solution either.

If you plan on having clients implemented on the browser (using javascript) a JSON based solution is the obvious path to follow, and it is simple too. For an aidea of what it would be like, please read this article:

• http://www.ibm.com/developerworks/web/library/wa-ajaxintro11.html

You can find more resources at json.org

You can probably use a JAX-RS just as a glorified Servlet implementation. (Many of us are saying that JAX-RS's JSR 311 looks like what the Servlet spec should have been from the start... which is not exactly that simple, but... )

About the "one thread per post" - that is a non issue since all the technologies you mention will behave that same way on most Application Servers / Servlet Engines - each request being processed at a given time will take its own thread.

(You are not talking about Comet here - a tecnhology which tends to take a thread per session unless you have a special bread of application server.)

Answer 3

Option 1 is a good option if you can make it efficient for your purpose. But I would like go for option 2 as long as option 1 is not required. Option 2 is well implemented and have good support. It should not create new threads every time if you use HTTP 1.1

But if you only have to transfer text then you can use your option 1 and some text compressing. Though there is a bit overhead to decompress the text it should too much. But it will reduce the bandwidth use of the mobile devices.

Answer 4

Sounds like to me that you would be best served by the HTTP protocol. It has a low overhead, already well accepted. Uses TCP [which is a requirement for mobile communication], it has session negotiation [well connection wise not the actual state of the session]

Use a different protocol for sharing of video and audio, but set the connection up with the http one.

Using SOAP/web services would not be optimal, due to the processing required. From personal experince webservice clients on mobile machines is easier but the processing required is tremedious and can create a bottleneck in your application. [Mobile machines don't handle threads too well]

Also: Since you are sending data over wireless you also have to account for the additional issues dealing with unguided media.

Your requirements:

• A server and a client. client is typically a mobile phone. : Yep
• Connected through the Internet. : Yep, depends on how your device network is setup
• Server and client want to talk to each other. : Yep
• Exchange of text, multimedia between the client and the server. : HTTP works well with text and images, but you need to switch to something unreliable like UDP for video.
• Text would be some standard format. that is predecided. : Yep
• Real time requirements : This is impossible, but can be attempted.
• Session would typically last for 5-15 minutes. In some cases for under a minute. assume 5 minutes as the session duration.: There are headers to keep the session open
• The protocol should adhere to standards. : RFC Something
• It must be efficient. : The only processing you have to do is line by line parsing of Key: data.

Also, I forgot to mention SOAP/Webservices is XML over HTTP.

Answer 5

Option 7 Why don't you go for XMPP?

• It's a standard

• it allows messages in both directions.

• you may use existing XMPP infrastructure (clients might connect using their Google Talk accounts for instance) or easily build your own using open source XMPP servers

• I also like the fact, that you basically only write client code (as the server is also an XMPP client) - assuming server and client are both written in same language, you may even use the exact same code.

• file transfers are supported.

• easily extensible to your needs

• it's buzzing (Google Wave) ;)

The only thing people might argue about is its efficiency - or the efficency of XML in general. I don't think it's a problem though.

Answer 6

The real-time need (if taken literally) cuts a lot of choices: the HTTP protocol is not real-time and so anything above it (including SOAP and REST) shares the same weakness. If this is a strong requirement you should look at the RTP protocol or something else that (at least) does not do handshaking.