Slashdot Mirror
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?"
Does anyone have any options that I may have missed?"
"My requirements are:
- object oriented
- extensible
- platform independent
- supports signatures for integrity and sender checking
- supports privacy of the message contents (i.e. encryption)
- time sensitive: I should be able to detect a dead server and do failover while the user is waiting for the response
- bandwidth efficient, as I am looking to deploy it in wireless environments
Does anyone have any options that I may have missed?"
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.
Just because TCP provides a sequenced, reliable byte stream with no need to transfer data past connection setup does not mean you can't use it to implement your application level requirements. Simply implement a null request with the client demanding a response within X seconds or you declare the peer dead (or effectively dead) and try another (yes this is a little simplistic and can result in livelock under heavy load but adaption, making X depend upon the peer's load and possibly dynamically measured response time, can help here).
And even if it does rule out XML per se, what's wrong with binary XML?
If you arent scared of 'scripting' languages,/ twisted
http://www.twistedmatrix.com/products
Haven't used it myself yet, but from the specs it seems to cover everything you could need.
If I had a DeLorean... I would probably only drive it from time to time.
Well I reccomend the good old time SunRPC. ;) There are other ways of doing OO..
It doesnt have 1. though that depends on what you mean by
"object oriented". I sense you want do export your C++ objects
It is somewhat lacking in 4 and 5 , though GSS-RPC will give you both. It is also not that difficult to implement authentication providers for sunrpc.. And for those that hate the portmapper, you don't have to use it. Another + is that it's small and fast. And you can do rpc over unix domain sockets, easing the pain to create custom protocols for interproces communication on the local box.
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.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Keep in mind that if you are truly cross platform and your communications are pure binary, then endian-ness will be an issue. I had to deal with this once when passing messages from a MIPS SGI to an x86 PC.
It can be a real pain when the underlying communication protocol blindly assumes endian-ness is the same on every machine. I prefer text-based protocols because they alleviate that problem.
There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.
The people behind REST seem to agree with you, I think.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol