Do We Need Another OO RPC Mechanism?

Paul68 queries: "I am looking for an RPC mechanism for a project. Granted, there are many to choose from, yet there seem none that meet my requirements! When one has toyed with the requirements the solution generaly becomes obvious. So, yeah sure, I can set out and create the next RPC mechanism, but it is a lot of hassle. But does the world need yet another OORPC, or have I simply not looked in the right corners?"

"My requirements are:

1. object oriented
2. extensible
3. platform independent
4. supports signatures for integrity and sender checking
5. supports privacy of the message contents (i.e. encryption)
6. time sensitive: I should be able to detect a dead server and do failover while the user is waiting for the response
7. bandwidth efficient, as I am looking to deploy it in wireless environments

Now #1-3 are no problem, #4 and #5 can be found, and #7 rules out anything XML-based. #6 seems to be the killer, as this rules out anything over TCP, and at that point the list gets pretty short.

Does anyone have any options that I may have missed?"

Comments

Does 6 rule out TCP?

[jrstewart]

I think you'll find that in practice a UDP-based solution isn't going to make your life any easier than TCP. You may want to use TCP in conjunction with an external timer to fail the connection well before TCP gives up though. If you tend to do multiple RPCs to the same host the overhead of TCP should be minimal, and you get a lot of functionality (retries, backoff, etc.) for free. There's RFCs for transactional TCP which solves some of the overhead problems for small exchanges but I don't think they're widely implemented.

If you do end up writing your own UDP-based protocol, take some time to study TCP as well as other UDP based protocols and make sure you write something network friendly. There are a lot of naive protocols which fail spectacularly in less-than-perfect conditions.

Re:Does 7 really rule out XML?

[kaisyain]

And even if it does rule out XML per se, what's wrong with binary XML?

Re:Something XML-RPC (SOAP) doesn't have

[Doomdark]

As for overhead, I'm in agreement there: the overhead of TCP/IP is definitely minimal compared to the cost of marshalling RPC data to begin with. TCP/IP can be tuned anyway, and it'll almost certainly be faster and more robust than something that tries to reinvent it over UDP.

Perhaps I misread original points, but it seemed like he wasn't so much worried about overhead, but about time-sensitivity aspect. TCP tries really hard to get all the data get through (with re-sends etc), without worrying at all about delays. It's good for bulk transfers, and things that simply have to get through, but for real-time (or in general time sensitive) data it's pretty useless to get anything that is late. And worse, since there's no way to really know what's going on (from TCP POV, "app shouldn't care"), it's difficult for the app to try to failover or other sensible action to resolve the (likely transient) problem.

Trying to figure out information about why and how data just isn't getting back, via socket (or whatever) API is next to impossible... thus, protocols such as RTP were developed. It's been a while since I followed what was happening there, but there was definite need for something that would give better control over timing information; at the very least for apps to be able to find out if there are timing problems, and do the right thing whatever it is (mark server as likely being down, find alternatives etc).

As to overhead, I'd agree; esp. due to HTTP being so ubiquitous, all stacks are ridiculously optimized, and handle "non-optimal" usage of TCP (simple request-reply) rather fine, all things considered.