Which RPC protocols work?

Posted 21 Jan 2001 at 17:09 UTC by emk Share This

And which are crawling, festering nightmares, devouring the sanity of anyone who uses them? Your personal experiences with remote procedure calls are eagerly solicited.

I just finished implementing an RPC library for one of my clients. This got me thinking about RPC in general. So when I ran into my friend Michael (a talented hacker and skilled ranter), I asked him about the available RPC protocols. As it turned out, Michael had been writing a research paper on distributed computing. So he'd been wading through specs, and he had plenty of material for a good rant.

But I'm also interested in real-world experience with various RPC protocols. Here's a list of some popular (and/or infamous) protocols:

  • Sun RPC: The protocol underlying NFS. There's a nice article at Open Resources.

  • DCE: An RPC protocol from the Open Group. I don't know much about this one. There's some more information on the Enterprise Linux page.

  • CORBA: An object-oriented RPC protocol with roots in enterprise computing. Currently used by Gnome, recently abandoned by KDE. Again, see the Enterprise Linux page.

  • DCOM: Microsoft's answer to CORBA; allegedly based on DCE. This appears to be available for Linux; see the Enterprise Linux page.

  • XML-RPC: A lightweight RPC protocol based on HTTP and XML. This is what I've been using recently. For more information, see my XML-RPC HOWTO.

  • SOAP: A not-so-lightweight RPC protocol based on HTTP and XML. Backed by Microsoft; submitted to the W3C. Microsoft has a resources page.

Which of these have you used? What were they good for? Did they fill you with warm, fuzzy contentment, or did they make you climb the drapes?


Sun RPC, posted 21 Jan 2001 at 17:18 UTC by gbowland » (Journeyer)

Sun RPC isn't too bad, seemed to work when I used it for an NFS client. It was fairly easy to use and there don't seem to be too many strange things associated with it.

If you're interested, here's a really good link to programming information (it is relevant to the Linux implementation, too): Tru64 RPC Programming Interface.

comments and further candidates, posted 21 Jan 2001 at 17:50 UTC by graydon » (Master)

I've used CORBA a fair bit. it's got good parts:

  1. receiver makes right byte order
  2. aligned messages
  3. async requests
  4. multiplexed connections
and bad parts:
  1. complex message structure
  2. method dispatch by string-matching
  3. several layers of abstraction and indirection between wire protocol and code
you might also want to browse 9P, which is pretty much the exact opposite of GIOP. it was designed as a minimal, programmer oriented protocol to present trees of "files" or file-like entities. no attempt made at object identity, mapping to procedures in a language, etc. yet you can accomplish all these things just by convention, and it seems to work quite well. the simplicity is refreshing: the whole marshalling/unmarshalling system occupies a single small man page.

CORBA vs. XML-RPC/SOAP, posted 21 Jan 2001 at 18:57 UTC by stefan » (Master)

the question whether to use SOAP or CORBA seems to be pretty popular these days. Being not a specialist in XML-RPC nor SOAP, I have however, a couple of concerns.

CORBA is much more than a RPC protocol. In fact, one of its strong points is to hide the precise invocation mechanism totally from the programmer. It is an architecture that enables programs to be written in a distributed environment, with a couple of requirements, among which are transparency and scalability.

One of the big problems I see with XML-RPC and SOAP is their exclusive use of port 80. That's not only a security issue, that's also a bottleneck if you need high throughput. It's definitely not scalable.

Another issue is the XML encoding of the data. It generates much more data to be marshalled than GIOP. Besides, CORBA has a precise IDL to GIOP mapping, i.e. once you know the server's interface, you can talk to it. I'v not heared about a similar feature in XML-RPC or SOAP. A DTD doesn't seem to be a good replacement for type definitions.

I'm using CORBA heavily in the berlin project, for a couple of reasons. First of all, its type system makes it easy to write a lightweight component architecture (see the recent discussion). Second, with its support for location transparency, it provides the means to define network transparent protocols that don't mandate the process boundaries (as compared to X, for example).

Java RMI, posted 21 Jan 2001 at 19:39 UTC by sergent » (Journeyer)

Don't forget Java RMI.

(No personal experience. I haven't found a good use for RPC yet in anything that I have done. I don't deny that there may be some justified uses. I just haven't seen any.)

Different kinds of RPC?, posted 21 Jan 2001 at 22:05 UTC by emk » (Master)

stefan writes:

A DTD doesn't seem to be a good replacement for type definitions.

I think this gets right to heart of the matter. CORBA is a high-performance, statically-typed protocol with strictly-defined interfaces. XML-RPC is a low-tech, dynamically-typed protocol. It's sort of like the difference between C++ and Perl. Both are respectable tools, but they seem to be intended for different purposes. :-)

CORBA has some very slick features. I'm especially impressed by ORBit's ability to make in-process CORBA calls without mashalling or demarshalling arguments. I also like CORBA's IDL--it's so much prettier than COM's IDL. If you need to be ultra-fast, and you want to define a custom, object-oriented API, CORBA is probably the right tool for the job.

But, on the other hand, there are situations when it's nice to be casual.

For example, I'd just soon not use CORBA for searching a website. For starters, the server would be a pain to write (you know your ISP doesn't want to hear about running another server process). The clients would need to include some kind of ORB. And anybody who wanted to write a client would need to master the CORBA bindings for their favorite programming language.

In a scenario like this, shipping around XML over HTTP appears to be an adequate solution, as perverse as it might initially sound.

Port 80 *not* required, posted 22 Jan 2001 at 06:23 UTC by dwiner » (Master)

One of the big problems I see with XML-RPC and SOAP is their exclusive use of port 80. That's not only a security issue, that's also a bottleneck if you need high throughput. It's definitely not scalable.

That's not correct. Neither SOAP or XML-RPC require port 80. SOAP doesn't even require the use of HTTP. We implement apps on all kinds of ports, and do others. FYI.

xml-rpc is "handy", posted 22 Jan 2001 at 08:35 UTC by Adrian » (Master)

The projects I'm currently involved with make heavy useage of xml-rpc. We looked at many possible alternatives including CORBA,SOAP, and a home brewed solution and decided to go with xml-rpc.

The primary reason being that it is simple. I would probabaly even so far as to say elegant. Simple enough to actually be useful. For the time being, it even seems to be violating the "conservation of misery" principle, but then, only time will tell ;->

I would suspect a good programmer with no prior knowledge of any RPC or component technologies could write an xml-rpc implementation quicker than they could learn to use CORBA. Now granted, xml-rpc has a fairly limited feature set in comparison to some of the other alternatives, but it's a great fit for a very large subset of problems where RPC is needed.

The primary benefits are:

  • Cross Language
    Versions are available for python, C, perl, VB, java, php,tcl and a handful of other languages.
  • Cross Platform
    More than likely just about any platform is going to have good support for one of the above languages/libraries.
  • Simplicity
  • Easy to leverage well proven robust technologies
    Our xml-rpc useages are all linux based, using apache, mod_python, and mod_perl. I have a lot of faith in those technologies for this kind of use.

Try it, you might like it.

CORBA , posted 22 Jan 2001 at 10:23 UTC by Stevey » (Master)

 I've used CORBA rather a lot, and I would recommend it, whereever possible.

 The big advantage of using CORBA is that its quite high level, and allows you to continue to think in terms of your problem, (be it objects, or methods), rather than having to worry about the transport mechanism.

 One of the biggest plusses that I can see with the use of CORBA is its sheer availability its possible to use CORBA from Java, Perl, C, C++, and accross multiple architechtures.

 I worked on a large project which involved distributed reporting, this used a CORBA server running on Solaris, with clients running on Windows - using either Visual Basic (Yeah;), C++, or Java.

  The really cool thing was that once the interfaces had been written we didn't have to worry about the byte ordering, or the marshalling, it was enough to invoke the method, and trust that it would happen.

Steve
---
Steve.org.uk

'Receiver Makes Right' Considered Evil, posted 22 Jan 2001 at 23:53 UTC by ncm » (Master)

graydon wrote, about CORBA:

>...it's got good parts:
> 1. receiver makes right byte order.

This has a comical history.

Sun RPC (like TCP) uses big-endian byte order, which is a nuisance when two little-endian boxes are talking. You'd like something adaptive. The most sensible is "sender makes right", because then you don't have to ask the receiver anything, and you can prepare byte streams before you figure out who they're for.

The problem is that "sender makes right" is patented. I don't know by whom, or when it expires. As soon as it expires, all new protocols should switch to it (including CORBA v.N). In the meantime, we have this "receiver makes right" which nobody had patented because it was too inept to consider seriously. The "sender makes right" is so obvious that it ought to be easy to crack it with prior art; evidently the DCE and CORBA people didn't have the stomach for such a fight.

CORBA must have got "rmr" from DCE, which was based in turn on on Apollo's AEGIS networking. AEGIS was groundbreaking in its day; some of its cooler features have still not found their way into IP-land. I don't know at what point "receiver makes right" got introduced.

Can anybody report when the "sender makes right" patent expires? Has there been any work on collecting prior art in case anyone is willing to challenge it?

What's wrong with receiver-makes-right?, posted 23 Jan 2001 at 05:50 UTC by apenwarr » (Master)

You said: The most sensible is "sender makes right", because then you don't have to ask the receiver anything, and you can prepare byte streams before you figure out who they're for.

Hmm, I'm curious - how is receiver-makes-right comical or somehow worse than sender-makes-right?

With smr, you clearly can't prepare a byte stream before you know who it's for, since if you want to "make it right" you must know the definition of "right." Worst case, this can require an extra round trip as sender asks "what byte order are you" and waits for a reply.

rmr should be the opposite -- the sender just sends whatever it wants, and the receiver fixes it when it arrives.

Or does one of us have our definitions backwards? I'm certainly not a CORBA expert.

XML's strength, posted 23 Jan 2001 at 06:08 UTC by taj » (Master)

XML-over-the-wire is generally very useful for low volume, fully specified transactions. The main reason is that there is not much hidden in the payload that may go wrong - both sides agree to a DTD or schema and that's (almost) it. After that you can implement this stuff in any number of environments without any fancy libraries or code - if you are using HTTP it's trivial.

Our first serious use of XML in the company I work for was sending quotes for auto repair to our web-based workflow engine from auto repair shop accounting programs - neither of the apps' maintainers were likely to learn something like CORBA for this stuff, but getting them to generate an XML document and send it via an authenticated POST request was no problem.

I love that you end up getting all the information for one atomic transaction in a single call. That is really a lifesaver.

OT: I find it quite annoying though that so much XML transaction stuff is going on in Java, a language that has not been picked up in the Linux world as readily as elsewhere. Most of the push for XML on Linux has been in the form of storage formats - while that's useful, XML really shines as a contextual data transfer format. Let's see some more XML tools for Linux!

Re: What's wrong with receiver-make-right?, posted 23 Jan 2001 at 09:02 UTC by ncm » (Master)

Avery wrote:

Hmm, I'm curious - how is receiver-makes-right comical or somehow worse than sender-makes-right? ... Or does one of us have our definitions backwards?

Somebody has it backward, and not just one of us. Here's a summary of the differences. They say "sender chooses" as the alternative, although they seem confused about the consequences. This one and this one suggest the opposite definition. Here's good discussion of the tradeoffs, although it seems DCE people have been mixing up endianness with automatic conversions of various "int" and float sizes, creating even more confusion. Feh.

It looks as if the consensus is on Avery's definition, given the confused description in the one contrary source. So, why do people complain about, in DCE, having to find out what the receiver wants so they can send that, and not being able to multicast? And why do they complain about the patent on just sending what you have? Maybe whoever I was reading was just confused.

According to the citations above, in real programs the Sun RPC choice, fixed network formats, wins on performance because you don't have to spend time figuring out whether and how to convert formats; you know at compile time and can code it in-line.

I'm sorry if I created any confusion.

receiver makes right, posted 23 Jan 2001 at 10:58 UTC by lkcl » (Master)

so you have a header. you have to have a header. the header tells you what function call this is and how much data you are sending. in the header, you specify the byte order.

now.

what exactly was the question / problem again?

there is an advantage to specifying that the receiver makes right. how much code do you need for each of the alternatives (ntoh, rmr, smr)?

ntoh/hton:

macros. both by sender _and_ receiver. lots of. great. you always, always have to call your macros. if you have a decent compiler, and you compile on the right architecture, your macros disappear. but not _all_ the time on _all_ systems.

smr:

the sender must convert to whatever data format the receiver accepts. that means that you must have an additional negotiation phase in order to detect what the receiver will accept! additionally, you'd better damn well not send what the receiver won't accept!

rmr:

sender doesn't even have to bother converting what it sends. in one simple "send" - simple because there _are_ no macros doing any damn conversion, and simple because the header just says 'it's this way round: deal with it' you have shortened the amount of work to be done: only the _receiver_ needs to do macros that convert or don't convert, depending on what they're told to do.

so, with an extra bit of work at the receiver end, you've saved a round-trip on the setup phase and simplified the sender's job.

seems to me like those guys patented the wrong thing!!!!!!! :)

XML / RPC, posted 23 Jan 2001 at 11:41 UTC by lkcl » (Master)

excellent! very pleased to see this available for c. has anyone considered adding security to xmlrpc?

"receiver makes right" and IIOP, posted 23 Jan 2001 at 13:39 UTC by jmason » (Master)

ncm said:

CORBA must have got "rmr" from DCE

Apparently IIOP got its marshalling and semantics mostly from a company called Expersoft, which wrote one of the first ORB implementations (along with Iona, who I worked for). So blame them. AFAIK they've since disappeared though.

I don't mind "rmr" over "smr", I agree with what lkcl said; "rmr" cuts out some negotiation, so it's a bit neater. I'd prefer TCP-style one-true-byte-order, as "rmr" does add extra complexity to your CDR marshalling code to handle both byte-orderings, but that's easy to test and not a big deal.

However, what I do mind is the broken packing and byte-ordering mechanisms, which mean that some complex messages can require full marshalling into a buffer multiple times, which can really kill performance, and can also mean that (for example) writing something like a transcoding transport-level proxy server is impossible, as you'll need knowledge of the interface to work out what each lump of bytes is representing. :(

My personal feeling on "which to use" is to prefer XML-RPC or SOAP; the main reason is that, as stefan pointed out, one of [CORBA's] strong points is to hide the precise invocation mechanism totally from the programmer. Which is IMHO a strong point sometimes, but if you want control over when you write to the network, and how to handle timeouts, non-blocking writes, and that kind of low-level stuff, you can't (unless your ORB vendor has added proprietary hooks to allow that).

Also, there's the readable nature of a SOAP request, which is nice; and very handy for hand-marshalling packets when you just want a quick hack. ;)

Gimme a lightweight library, where I control the sockets, anyday ;)

XML-RPC security progress, posted 23 Jan 2001 at 13:50 UTC by emk » (Master)

lkcl writes:

excellent! very pleased to see this available for c. has anyone considered adding security to xmlrpc?

The RedHat Network uses XML-RPC over SSL, which seems like a good first step. And Karl Wallner is porting xmlrpc-c to work with curl, which should also support SSL.

For the export-controlled, one or two of the XML-RPC clients also support HTTP Basic Auth. And KDE's kxmlrpc stores a cleartext token in a read-only file in your home directory.

So there is some security stuff being worked on, but it isn't yet universal. In particular, more non-US developers are needed to work on SSL. (And I need to extend the xmlrpc-c API so the client can add authentication tokens. Doh!)

DCE/RPC over SMB: Samba and Windows NT Domain Internals, posted 23 Jan 2001 at 17:02 UTC by lkcl » (Master)

ISBN 1578701503.

funnily enough, it describes:

briefly the history and politics of dce/rpc and how it got into NT.

enough SMB to use it as a transport for DCE/RPC

enough DCE/RPC to implement the minimum for interoperability with NT

enough DCE/RPC over SMB services to implement a Windows NT Primary Domain Controller or a Domain Member Server.

dce/rpc over smb and these services can be implemented in c in under 80,000 lines of code.

contrast this with the dce/rpc 1.1 runtime library which, as i have pointed out before, is 250,000 lines with _no services_.

if you go the whole hog with dce/rpc you have:

- transport independence. TCP, UDP, DECNET/3.0, SMB (including SMB over TCP, IPX and NETBEUI because SMB runs over NetBIOS), IPX/SPX, HTTP, NetBIOS (direct, not via SMB), NETBEUI, and basically anything you can get your hands on.

- security independence. NTLMSSP, Kerberos (4, 5 and ms-modified), GSSAPI, noauth, and others.

- full and _complex_ c syntax data structures. CORBA's IDL is missing the capability to do arrays of encapsulated unions, iirc correctly. full pointer marshalling - e.g. you can successfully pack and unpack a doubly-linked list with DCE/RPC's marshalling/unmarshalling - something that i doubt any of the other IDLs can handle. note: full pointer marshalling is quite heavy, code-wise, so not even microsoft bothered with it in their implementation of DCE/RPC!!!

- negotiation of ascii _and_ ebdic.

if you are wondering what this is all about, then at least appreciate this: DCE/RPC is the mechanism behind DCOM. please bear in mind that both CORBA and DCOM are object models. they make use of a standard "RPC" mechanism as the basis for an "object" system. theoretically, CORBA could use DCE/RPC as its... er.. "transport" for its objects and their associated functions, and DCOM could theoretically do likewise with CORBA's underlying RPC mechanism.

so the question that mentioned CORBA and DCOM as possible RPC mechanisms to use, and which do you prefer, is a little misleading.

[question: does anyone know the correct name of the CORBA underlying RPC mechanism? is the RPC mechanism sufficiently self-contained to be able to make use of it _without_ CORBA's object stuff on top of it, is another way of putting it?]

i have worked with [from over-the-wire] dce/rpc for over three years, now. i am very impressed with it. future plans [jeopardised by the primary samba maintainers] included extensions to TCP and HTTP transports in order to implement an epmapper, and then move on to an exchange client / server (which is basically using DCE/RPC over TCP as an authenticated transport for the MAPI transport, if anyone's interested. microsoft _really_ do believe in making life difficult, but seem to achieve a hell of a lot more than anyone _else_ does, so don't go bitching and bashing unless you can do better, which i doubt, to be really blunt and honest. yes, i'm issuing you a challenge there. make my day: prove me wrong :-).

i investigated the dce 1.1 rtenv, primarily because it already had the TCP transport in it, and found it to be somewhat lacking. i tried to add NTLMSSP to it, and freaked out. Jim Doyle, formerly of bu.edu, had done a _lot_ of work porting the dce 1.1 rtenv to Linux. primarily, he had made the IDL compiler work with flex / bison, which he said last time i spoke to him that it was a tough job, taking up most of his time. he then went on to provide a "hack" job implementation of DCEthreads, which are Posix (Draft 4) Threads and he implemented them using sigsetjmp and siglongjmp, which works under redhat 5.2 as long as you don't expect to use a debugger, and fails immediately under glibc 2.1 even _without_ a debugger: it goes into an infinite recursion loop and runs out of stack.

so, if someone is seriously considering doing dce/rpc development under open source unix for interoperability with nt, then first thing that's needed is a _portable_ version of DCEthreads. second, you need to add NTLMSSP as a security mechanism.

alternative: help with the samba tng Hg and sidlc projects. our aim is to provide the missing transport TCP (we have a local loop-back and SMB transports already), write an IDL compiler (sidlc), then we can implement an endpoint mapper daemon, maybe add thread support (which is a dodgy and thorny issue and there are ways to avoid needing threads), and _then_ the code will be in a position to implement things like an exchange server / exchange client, with a full native open source alternative to the Win32 MAPI api (then people can compile all their favourite win32 mail clients without modifying the source too much!), maybe we'll go for an MS-SQL 7.0 API, too: it would make writing a _native_ ODBC driver for unix utterly trivial (none of this daft odbc-odbc bridge stuff).

i think you get the idea. DCE/RPC is embedded in ms applications like you wouldn't believe. and because of the samba tng project, technically, the gap is now a hell of a lot narrower than most people realise. including my former employers.

"receiver makes right", posted 23 Jan 2001 at 17:09 UTC by db » (Master)

Actually I was in the room when it happened, and you've all got it wrong!

IIOP has a bicanonical encoding. That means there's a big-endian (network order) and a little-endian (Intel order) encoding for every integer or floating point. And it only uses IEEE floating point.

That's not the same as "receiver makes right", the scheme used by DCE (and hence allegedly DCOM) ... because there are only two canonical encodings, not something like eight. DEC RPC has all sorts of nasties like padding and alignment restrictions varying on the originating CPU (the model is to slam structs into marshaling buffers and let the receiver figure out alignment/padding), and multiple floating point formats.

The considered opinion of the folk who settled on that bicanonical form was:

  • The justification for a bicanonical form was political ("maybe DEC/MS can swallow it"); it was acknowledged to be sub-optimal.
  • As a political accomodation, it wasn't enough. DEC/MS would only accept DCE-RPC, which no technologist in their right minds would accept (way too complex, huge adoption/exit costs).
  • A single canonical representation, as used in XDR (Sun/ONC RPC) would have been better. Cheaper in terms of cost (as widely noted) and design consequences.

That said, IIOP is still quite a usable scheme, with advantages including wide availability. Particularly compared with bloated schemes like those used in RMI or SOAP, where extra type data must be explicitly carried in every request ... lots and lots of it, bloating the size and processing costs to an extreme. (There's no good reason to carry that around in the typical case where both sides of the operation already know it.)

XML based protocols are the latest trend, and certainly Microsoft likes them because to the extent they're adopted, they prevent non-Microsoft protocols like CORBA from gaining further ground. But I can't be all that keen on protocol designs which aim to undermine security (by promoting firwall tunnels) as much as Virus-X. And anyway, don't we need another RPC protocol like a fish needs a bicycle? :-)

- Dave

killing performance, posted 23 Jan 2001 at 17:19 UTC by lkcl » (Master)

However, what I do mind is the broken packing and byte-ordering mechanisms, which mean that some complex messages can require full marshalling into a buffer multiple times, which can really kill performance, and can also mean that (for example) writing something like a transcoding transport-level
killing performance? ha!!!! that's the _least_ of your worries. i often describe sending semi-random data to NT4 as like walking through a minefield where the mines are guaranteed to be four inches apart :) :)

i gave up sending reports in to microsoft about the state of their marshalling and unmarshalling code [apparently, someone disabled the safety-checking in the compile for the final release build!!!!] for NT4 because there were just... so many ways to crash critical services, it wasn't even fun any more.

by contrast, and probably because i was finding bugs at the rate of one per two to three weeks whilst trying to network-reverse-engineer their NT Domain functions / services, they did a _total_ rewrite for NT5 (aka w2k) of the marshalling / unmarshalling and the security API. other than one or two quite serious (black screen of death) bugs, i find it really really difficult to crash NT5.

the point / moral of the story: use a decent, correct IDL compiler and supporting marshalling / unmarshalling library!

alignment, posted 23 Jan 2001 at 17:38 UTC by lkcl » (Master)

because there are only two canonical encodings, not something like eight. DEC RPC has all sorts of nasties like padding and alignment restrictions varying on the originating CPU (the model is to slam structs into marshaling buffers and let the receiver figure out alignment/padding), and multiple floating point formats.
i presume you mean dce/rpc not dec rpc, even though it was dec doing most of the coding for the 8 million line dce 1.22 CDS, DFS etc. services :)

you are wrong about the model being .... etc.

there are no padding / alignment "restrictions" which vary on the originating CPU, for a start. the int types supported are uint8, 16, 32 and 64.

the IDL compiler generates code for client and server. the receiver therefore doesn't "figure out" alignment / padding. let me see if i can find the part in the spec for you.... ah, here we go. http://www.opengroup.org/onlinepubs/9629399/toc.htm. let's find the bit on alignment... yep! alignment of primitive types. well, the spec doesn't give any examples. let's say you are at offset 0x5, and you have to read a uint32. you must skip ahead to offset 0x8 and you will find / place the uint32 there. the receiver follows these rules; the sender follows these rules, because the IDL told you to read a uint32 next.

what was the problem again?

regarding floating point representations, i cannot inform you there: none of the network traffic i have been reverse-engineering has used floating point (or ebcdic either). however, if you asked me to venture an opinion, allowing for the negotiation of (actually, it's just - like rmr - that the sender _tells_ the receiver, here, you're going to use this, today) different floating point formats seems pretty future-proof and stops damn committees from arguing the pointless toss.

dce/rpc floating point, posted 23 Jan 2001 at 17:42 UTC by lkcl » (Master)

urr, yuck!!! NDR has IEEE 754, cray, VAX and IBM floating point formats!!!! eeeuw! well, at least you can be sensible and say, hey, i couldn't care less about anything other than IEEE these days :)

look into the E secure distributed language, posted 23 Jan 2001 at 17:44 UTC by Zooko » (Master)

All these RPC mechanisms have an underlying assumption the both computers trust each other completely (sometimes this assumption is explicit, sometimes not, sometimes there are compensating mechanisms, sometimes not). This may be useful for back-end business apps where all the computers are owned by the same organization and there is a full-time sysadmin staff running around checking to see if any of the computers have been compromised, but it would be a big mistake to start with this assumption when writing distributed Internet applications.

Check out the E Language, which starts with some very strong assumptions about security and trust and ends with a sophisticated, elegant tool for distributed applications. A good place to start is the QuickE 15 minute tutorial.

implicit trust, posted 23 Jan 2001 at 17:52 UTC by lkcl » (Master)

All these RPC mechanisms have an underlying assumption the both computers trust each other completely
in the case of dce/rpc that is not the case. dce/rpc has authentication (and auth negotiation), and the security then negotiated can use the signing and sealing mechanisms on PDUs to provide tamper-proof and encrypted function calls.

i had to implement this, remember!!! :) the algorithms used by microsoft (NTLMSSP v1 and NETLOGON Schannel) are described in ISBN 1578701503 if you're interested, and NTLMSSP v1 and _part_ of v2, and the Schannel, are implemented in samba tng.

so, only if your security mechanism - or lack of - trusts both computers completely do you have no security, in dce/rpc.

security, authentication, posted 23 Jan 2001 at 20:35 UTC by Zooko » (Master)

This might seem weird, but I consider authentication to be almost completely useless for security.

I mean, granted I use ssh to authenticate my connections to remote machines so that I can log in and work there (and the E Language provides that kind of encryption and authentication transparently to the programmer), but this is the case of both sides trusting each other and needing security solely to protect themselves against a hypothetical third party. The much more interesting case (at least to someone like me who works on distributed systems like Mojo Nation) is that you don't know or trust the computer on the other end of the connection, and you need security from them while also cooperating with them.

This seems to be the kind of security that we most desperately need on today's Internet.

How many of the exploits that have paraded by in the past few years would have been prevented by ubiquitous, forgery-free authentication on all connections and digital signatures on all source code? Zero. No exploits (as far as I know) have depended on using an unauthenticated channel or replacing a well-known piece of code with a Trojan horse before that code is delivered to the victim.

The actual issues in security, both present and future, fall into two categories: 1. code that you run on your system that accidentally betrays you due to bugs or design flaws or 2. code that you run on your system that maliciously betrays you.

Neither of these problems are solved by authentication. Both are addressed by E. The first by providing a simple, elegant, flexible security model with accompanying language support so that programmers can easily design and audit secure code[1], and the second by "capability" security[1], the uniquely flexible and secure method of restricting code from doing certain things while still allowing it to do others.

See this article by science fiction author Marc Stiegler for an example of a simple secure application that is easy in E but probably impossible in any other current system.

Regards,

Zooko

[1] Well, at least it looks nice. I haven't actually written any code in E yet, but Marc Stiegler has, and he's not even a real programmer -- he's a lowly science fiction writer.

[2] Note: "capability theory" in security -- originally in secure OS design -- has been around for decades. Recently some people, notably Linux hackers, have been using the word "capability security" to mean something else -- basically fine-grained access control. An unfortunate pollution of the namespace...

location transparency and fine grained control, posted 23 Jan 2001 at 21:13 UTC by stefan » (Master)

jmason: I agree with you that at times you want to control the details of the communication. So do the CORBA architects, apparently.
You may be pleased to read about the new Messaging QoS Framework (for example here). In fact, it appears this reflects CORBA's evolution in general. It first tried to hide everything from the user, and as people are using it and ORB implementors add useful (but proprietary) extensions, they fill in the important pieces to standardize lower level control mechanism (see the BOA -> POA step, for example).
The philosophy seems to be: as low level as necessary, but not more

Encoding Schemes, posted 23 Jan 2001 at 21:15 UTC by sarum » (Journeyer)

Wow, intresting stuff, I came to this thinking smr was the correct encoding scheme, with a small amount of thought I am convinsed that it uses less machine resources. Note I did not say faster or better. This because in reality unless we are talking about encoding large data structure (and the app I work on IRL can send 1M ones) it is the transport time which is so much larger than the encode time it is almost irelivent. But that said if you have a bizzy machine which is getting a lot of calls it might make a difference, but for a file server I very much doubt it as getting a block off the disk is also orders slower than the encoding. In fact I have never seen a NFS server which has had a CPU problem even if it thrashing the disks. It is much more likely to be limited on the ethernet or disk IO.

In all engineering you have to deside what you mean by 'best' and in this case to me it seams that 'best' means the data gets into the ABI format correctly at the recieving end. IMHO this means that you should have a standidized format so that less ABI X to ABI Y code needs to be in each library on each machine. In rmr this effectivly means if I change the size of a DT then all the recievers need new library updates. This sounds like a reasapy for incompatibility. So unless there are any other reasons to me it seams h2n/n2h is best.

RPC - what you think?, posted 23 Jan 2001 at 21:32 UTC by sarum » (Journeyer)

I have been programming client server systems for 12 years, the first systems where simple BSD sockets app using standard event / select loops with our own encoding system (normally to text). It took a long time after I found out about RPC/IDL technology before I could find a project team / company brave enough to build a system with it. And that is what we have been doing at Monotype System for the last 5 years. Initially we looked into using ONC/RPC, DCE/RPC, CORBA, and DCOM which where the 'leading' technologies in the feild at that time. We rejected all but Sun's ONC because the other where not avaiable for free on other platforms (at that time). Having the source also meant that we could port it to any other platforms as needed.

I designed and build a set of classes on top of the base level RPC API to shield the low level API from everyone else, but crutially I never tried to hide the network calls from the programmer. There was no attempt to make a network method look like a standard C++ method. Hence when a programmer uses the network call there is a whole lot of setup and checking code which must be hand written for each call. This means that the coder is not deluded into thinking that the call will be 'quick' or 'error free'. This is one of the problems of using a standard RPC system. You can be fooled into think that the getpwent() call is part of local API and will not make any calls to other machines.

Generally using ONC/RPC has been a great success we have built and sold lots of servers specifically for different customers requirements and they all interoperate transparently. Hence as far as I am concerned "it does what it says on the tin". :-)

Hg - What is that then?, posted 23 Jan 2001 at 21:50 UTC by sarum » (Journeyer)

I thought as we are on the topic of RPC systems I might tell you about my dream called Hg.

Hg?

Hg -> Mercury -> God of Communication & Transport

Cute name, so?

The TNG-Samba project Hg has two main goals:

  • provide a MS-DCE (like) implementation that can be used by TNG-Samba
  • write a RPC independed API library

What was that?

The second goal is to write a simple API which can be used to connect and commicate with any server that has a 'resnoble' protocol and make it look like they all work the same way. So just by creating a connection to a DCE/RPC server telling the API that it is a DCE/RPC protocol you can communicate to it using the same API as the one used to do the same to ONC/RPC or MS-DCE/RPC or even HTTP, DNS servers etc.

Anyone intrested?

What you all thing? Could it be done? Should it be done? Does anyone want to have a go?

So they all "work", but they don't suit me..., posted 23 Jan 2001 at 23:12 UTC by gtaylor » (Master)

Basically everything listed does in fact make remote procedure calls. This is, however, a bit limiting, since the very concept of a function call maps poorly into the network domain; this is why asynchronous messaging features inevitably get bolted onto these systems.

What I've been looking for lately is something with just that: I'm looking for a general-purpose messaging system which allows for various pleasant sorts of asynchronous message passes, muxed i/o aka select() processing while waiting, and so forth. (By async message passes, I mean you can make assorted remote calls--some expecting responses and some not--with a nonblocking API, and then you can go about your business, examining the status of all outstanding calls at whim, or blocking for the respons(es), or continue after having registered response handler callbacks as you prefer).

The best free alternative I found was to build atop arpc, which is a fully nonblocking implementation of sunrpc-style messaging, with a few nice enhancements. This supports more or less arbitrary arrangements of synchronous and asynchronous message-passing processes in a network, without being limited to the rpc-style invokations emphasized in the usual suspects. It works properly in traditional select()-based event driven Unix programs, or, since it's nonblocking, could be trivially adapted for threadsafety. Curiously, the authors then turned around and implemented the original synchronous RPC semantics atop arpc as the Q system; I supposed this must have had some root in their Ada work.

The second-best free alternative was DIPC, which provides network forwarding of sysvipc syscalls (and shared memory pages), and thus provides end-to-end guarantees for the various msgxxx functions. This didn't suit since it had a round dozen ways to die a horrible death: there are scads of plumbing processes, and the thing isn't really built for performance in the first place.

Unfortunately, here at work we've tentatively decided that the nonfree system NDDS might be a better option, since it would require basically no work up front. It's got a number of features that are nifty from a reliability standpoint, and offers a marginally easier API, being a (really expensive) commercial product and all. But that easier API is due in part to a surprisingly thread-heavy implementation, which makes me nervous just on principle.

So are there any others? I hate to pay the extortion-level pricing for an NDDS source license when this is clearly the sort of infrastructural software that really ought to be LGPL.

XML-RPC, SSL, nationalism, posted 24 Jan 2001 at 00:36 UTC by wmf » (Master)

emk, what does US/non-US have to do with adding SSL support to XML-RPC implementations?

XML-RPC, SSL, and export laws, posted 24 Jan 2001 at 02:03 UTC by emk » (Master)

wmf asks:

what does US/non-US have to do with adding SSL support to XML-RPC implementations?

The U.S. government considers cryptographic software to be an export-controlled munition. This is why many web browsers come in two versions: a version with 128-bit SSL for domestic use, and a version with 40-bit SSL for export. The 40-bit version is basically worthless--you can break it in a college computer lab in an afternoon.

The export rules have recently been relaxed (especially for published source code), but it's still a big headache.

Does anybody know if RedHat's XML-RPC code supports 128-bit SSL? This is definitely where I want to go in the future.

security., posted 24 Jan 2001 at 13:57 UTC by lkcl » (Master)

This might seem weird, but I consider authentication to be almost completely useless for security.

I mean, granted I use ssh to authenticate my connections to remote machines so that I can log in and work there (and the E Language provides that kind of encryption and authentication transparently to the programmer), but this is the case of both sides trusting each other and needing security solely to protect themselves against a hypothetical third party. The much more interesting case (at least to someone like me who works on distributed systems like Mojo Nation) is that you don't know or trust the computer on the other end of the connection, and you need security from them while also cooperating with them.

hm. fascinating. so, if i understand you correctly, E is basically a more secure version of the Cambridge Capability System (searches with google didn't show this up, i would look more if i had more time but this url looks more cluefully up-to-date anyway: http://www.cis.upenn.edu/~shap/proposal/proposal.html)

you are right. the NT NETLOGON service basically makes _use_ of DCE/RPC to provide a secure user-logon and SAM database replication mechanism from explicitly-named trusted hosts (similar to NIS+).

this mechanism is in no way built-in to DCE/RPC.

_however_, what they did was, having written the NETLOGON service, they then _used_ that DCE/RPC service to do NTLMSSP authentication for other DCE/RPC services! and no, it's not recursive, because NETLOGON can be connected to anonymously.

even when you _can_ add security into DCE/RPC services, it is *explicitly performed by the service*! even using the authenticated user's security context is optional! it is recognised that this is something that services may wish to do, and so there are a series of functions (in both the dce rtenv lib and in the samba TNG / HG codebase) that can be used to check security context and to seteuid - _if_ the service wants to. and quite often, you simply don't have to!

so, anyway: saying "services implicitly trust each other" is a bit misleading. services only implicity trust each other if that is what you have designed (quite probably by omission from the design, more than anything else) them to do. dce/rpc _does_ provide the means for a designer to actually make use of the security context: how else could only an Administrator be the only one allowed to add user accounts with USRMGR.EXE (nt) / samedit (samba-tng)?

EROS, E, RPC, mobile code, the Internet vs. the back-office, posted 24 Jan 2001 at 15:51 UTC by Zooko » (Master)

Right, E is inspired by the capability secure operating systems, as well as others. The difference is that while EROS is an operating system, running on bare metal and confined to a single machine, E is a language, running on an OS, and running distributed programs across multiple networked machines.

I see what you mean, that RPC mechanisms like DCE/RPC can be used to perform authentication more fine-grained than simple connection authentication. Still, fine-grained ACL-style authentication doesn't seem as useful to me as a capability environment like E. Consider a couple of examples:

  • I want to register a remote procedure with a server, like mp3.com, so that it can asynchronously contact my home computer and inform me about new developments, e.g. a new tune has appeared that matches my preferences. I don't want my home computer to be subverted by mp3.com, (whether or not I have authentication proving that it was really mp3.com from which the procedure was invoked). So I need to audit my local procedure implementation and guarantee that no mistake on my part, and no malicious mis-use on mp3.com's part, can result in my operating system being compromised.

  • I want to accept an agent -- a small script -- from a remote computer, like folding@home, and run it when my computer is idle, without risking that my entire operating system could be compromised by the agent if it is malicious. Again, if my operating system is vulnerable to the agent's misbehaviour, then having the agent signed by "folding@home" reduces my risks a little bit, but not much. This is because a hacker (or a malicious person who works at "folding@home"), would first have to compromise "folding@home" before they could compromise my computer. Once they compromised my computer, then they could distribute agents signed with my key to further victims -- a great plague of digitally signed virusses. I would much rather just be able to run the agent in such a way that it can't hurt me. Then I don't have to worry so much who has signed it or not.

  • I want to try out a new program, for example, a new game by a new, previously unknown author. If you think about it, all of the code on your computer, except for the code that you wrote yourself, is "mobile, untrusted" code. You downloaded it over the net and installed it and ran it, taking your chances and hoping that neither the authors nor any intervening hacker installed a Trojan in it.

So in my opinion, the RPC mechanisms that have been described in this thread are fine for situations in which both computers are controlled by the same entity and do not have to be mutually suspicious of one another, but these mechanisms fall completely flat (with or without authentication or ACLs), when it comes to interoperating programmatically with a machine that you do not trust. Personally, it is the latter situation that interests me most.

Re: Does Red Hat's XML-RPC use of 128-bit ssl, posted 24 Jan 2001 at 17:52 UTC by Adrian » (Master)

That would be "yes". It is based on openssl which is included in Red Hat Linux 7.0 (with retrofit packages available for 6.2). And it does validate certificates as being signed against a CA (in this case, the CA certificate is shipped in the GPG signed packages)

Since the code is available, the export restrictions are far less than they used to be. So aside from various algorithmns that have to be disabled/removed because of US and european patents, the openssl libs as shipped should support most everything openssl does.

Keep in mind that this is just the outer wrapping for this useage of the xml-rpc protocol. Each call to the server also includes a authentication token. xml-rpc itself doesnt really include any support for authentication beyond that which the underlying http layer provides. In the case of the Red Hat Network, we make use of certification verification, and ssl session encryption at the http layer, and app layer authentication above the protocol.

XML-RPC/SSL, posted 24 Jan 2001 at 20:03 UTC by emk » (Master)

Adrian writes:

Since the code is available, the export restrictions are far less than they used to be. So aside from various algorithmns that have to be disabled/removed because of US and european patents, the openssl libs as shipped should support most everything openssl does.

Cool! Is there a good source of information on current export restrictions? Everyone says they've been relaxed, but nobody seems to know the recent court cases actually apply in practice.

The xmlrpc-c library uses w3c-libwww for HTTP support. There are some third-party SSL patches available for w3c-libwww, so enhancing the client shouldn't be too hard.

In the case of the Red Hat Network, we make use of certification verification, and ssl session encryption at the http layer, and app layer authentication above the protocol.

This seems to be the Right Thing(tm). It's certainly a natural and obvious extension to XML-RPC.

Crypto export relaxation, posted 24 Jan 2001 at 20:51 UTC by wmf » (Master)

AFAIK, there aren't any court cases that apply to the relaxation in crypto export rules. You can probably find more info in the Mozilla crypto FAQ or netscape.public.mozilla.crypto. Unfortunately I have to run off to class right now.

crypto export restrictions, posted 24 Jan 2001 at 21:28 UTC by mattbradshaw » (Journeyer)

re: emk's request for offical crypto export control status

i think that most of the aforementioned relaxed crypto-export policy has come in the form of new legislation and executive orders... here are some urls that might be acceptably 'official':

there is one court case that also may be of interest to you, the well publicized bernstein v. US DoJ trial. a lower court ruled that source code (cryptographic or otherwise) is protected under the first amendment and as such bernstein has been granted the right to step over the export restrictions. this ruling may well be overruled on appeal, though. news concerning the case is maintained at the eff . basically, this is still in the air as we're still upholding the current regulations until the appeals process for the case runs its course.

looking through these links i've just given just makes me (again) realize how awesome the eff is. need to donate...

hope this (boring) info gives you some help and confidence in your legal right to include cryptographic components in your xml-rpc library. when i first started hunting for this info, the mozilla project was a great help. btw, thanks for the excellent/helpful/superlative library! i see a great many uses for it. regards,
--matt

IDL for XML-RPC?, posted 26 Jan 2001 at 03:50 UTC by emk » (Master)

stefan wrote:

Besides, CORBA has a precise IDL to GIOP mapping, i.e. once you know the server's interface, you can talk to it. I'v not heared about a similar feature in XML-RPC or SOAP.

I'm currently working on it. ;-)

Now that xmlrpc-c supports introspection, you can query a server for a list of supported methods, get a machine-readable API description, and dump it to the console.

The next step is to automatically generate C++ (or Java) wrapper classes for the entire API. This isn't too hard, because XML-RPC has such a simplistic data model.

Once this is done, you should be able to turn a server URL into a complete set of client classes. This would be a Good Thing(tm).

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page