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 the Internet.
• Server and client want to talk to each other.
• Exchange of text, multimedia between the client and the server.
• Text would be some standard format. that is predecided.
• Real time requirements
• Session would typically last for 5-15 minutes. In some cases for under a minute. assume 5 minutes as the session duration.
• The protocol should adhere to standards.
• It must be efficient.

Option 1 A binary protocol that I design for my application.

Option 2 Implement my server as an HTTPServlet. Client sends post requests and the query in the post message and servlet sends response in the message. However, I think that for real time interaction, this is not a good option as a new thread would be created for each post request even for the same client and session. Please comment on the efficiency of this.

Option 3 Use a normal servlet. Would face the same problem as above.

Option 4 Use SOAP

Option 5 Use REST

Option 6 Use Google Wave (I haven't read the specification yet)

Option 7 Suggest some other protocol

Right now, I don't have experience with web services, but if it is the option then I don't mind investing time in it.

Basically, I want the speed and efficiency of option 1 with a standard way of doing things.

Thank you

Hartfield

If this is a poll/vote, could you please make it community wiki? – Lightproof

(a) can you elaborate on real-time requirements? (b) are there any security requirements? – Opportuna

@Jeremy it is a still a design decision, is it not related to programming. – Hartfield

@Michael - question from client, response from server. response could be multimedia content also. thus interaction has to be done in real time. i think servlets are good for browsing. Yes there are security requirements. But for the prototype no. – Hartfield

Does the data need to be secure, i.e., encrypted? – Swish

Your comments on Option 2 are somewhat invalid. Both SOAP and REST are implemented on top of http, so the "new thread per request" applys to them also. I would regard this as a feature: it improves overall performance by not holding resources between requests and enables scalability, load balancing and high availabilty. – Openair

@James, SOAP doesn't have to be on top of http! SMTP is also used as application layer for SOAP, although most people won't use this anymore. – Overprize

Answer 1

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.

Sherborn

i would invariably use a data structure at both ends to send the data. now it seems that i have to encapsulate the contents of the data structure in a HTTP request. i would need to parse the data structure at both ends. what do you say about Google Protocol buffers as Adamski suggested. – Hartfield

Depends on the requirements of the mobile device... With PPC+high specs otherwise use GPB b/c its easier Most mobile devices are generically low performance devices, b/c the main focus is extending the battery life as much as possible. Rule of thumb: If the device has a GSM/CDMA modem it will have a low end cpu to save power. code.google.com/p/protobuf Issues with this: 1. It extends HTTP protocol [not a bad thing but not barebones] 2. Adds extra characters [this can delay transmission] 3. Third Party component is used (this will make your executable bigger) – Sherborn

Well I just looked it up, I thought given Google's main task everything they did was pretty much HTTP. After a look through their tutorial: Google Protocol Buffers are nothing but a new way to serialize data. So that means that you can use any protocol (including HTTP) with GBP. In a mobile environment you can not afford loose coupling of items as you can on desktop environments. In a mobile environment you need speed (with a reasonable development environment) and effeciency (non-efficient code wastes power). – Sherborn

Answer 2

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.

Recurvate

+1 I was about to add XMPP as an answer, but you beat me to it. It's the obvious way to go. PubSubHubbub is the other possibility that might make a lot of sense. – Engracia

We aren't sure what kind of mobile devices that he is targeting but the XML processing isn't exactly quick on mobile processors. – Sherborn

@steven: That's true, but XMPP's XML documents are quite short anyway. thus making XMPP suitable for most mobile processors. – Recurvate

Answer 3

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.

Selfseeker

Answer 4

Use option 1, use ASN.1 as protocol! (Sometimes called binary XML.) This results in small, structured messages that can be understood by others. It's a popular standard and when you're reading this message, you've just used it. :-)

ASN.1 is part of several Internet protocols.

Overprize

As I understand it, ASN.1 is expensive to parse. It isn't self-describing, so the parser has to recognize any possible encoded object, which makes migration difficult. With self-describing formats, older code can easily recognize and ignore new syntax. – Mcgee

There aren't many ASN.1 parser libraries and those that exist tend to be a bit expensive. But it's an open standard and generates very little overhead. I've used it in the past as part of a communication system with a PBX system, where the PBX hardware required to receive it's orders in ASN.1 format. There are basic readers available that can read any ASN.1 message and combined with an additional protocol description it's easy to use those readers to analyse the complete message. – Overprize

Answer 5

Go for option 1 and use Google Protocol Buffers to autogenerate your code from the protocol definition (i.e. it gives you some consistency / standardisation whilst still being efficient).

Snappy

Or Apache Thrift (was developed at facebook) – Grindle

Answer 6

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.

Snider

Answer 7

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

Lakes

no typically there will be an application on the mobile and not a browser. i'll look up about comet and comment later. – Hartfield

how about comet like server behaviour? – Hartfield

how about comet like behavior? – Hartfield

Answer 8

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.

Lilybel

Answer 9

Hessian is a lightwieght binary protocol over http. There are a lot of different Hessian implementations so you could serve a number of different clients.

Since you're concerned with efficiency, you can find some metrics on different Java remoting protocols here: http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/

Iou