As you may deduce, I’m a huge fan of unmanaged remote procedure call systems. They serve as the building blocks for most distributed systems problems. They provide an easy programming model – synchronous function calls. They have a small memory footprint (unlike managed systems like Java and C#). DCE/RPC and Sun RPC are the two widespread models (one is the foundational technology for Windows operating systems) and the other atleast is the basis for NFS infrastructure.
DCE/RPC on UNIX platforms has been in wilderness for almost a decade. Hopefully Likewise’s rehabilitated DCE infrastructure can bring about some form of a renaissance of an unmanaged, easy to use, remote procedure call infrastructure. But I digress. I wanted to talk about lwmsg.
In the Windows world of systems programming, user mode clients and servers are built around a particular paradigm. Let say we are building the foo client -server system. Foo will have a client dll – the fooclient.dll that exposes DLL entry points for a calling client application to link to. The calling client program has no
When we started on lwis, we wanted to build that Windows style programming pattern – we could have used DCE/RPC using ncalrpc, but at the time, I was worried about the chicken-and-egg effect. We wanted API style communication to the lsassd daemon, but one of the primary interfaces would be our gss-ntlm client and our gss-ntlm server. The DCE/RPC system would use NTLM as one of its authentication mechanisms, so wouldn’t that mean we would be using DCE/RPC to bootstrap itself? So we decided that we would need an effective authenticated remote procedure call mechanism that would handle communication between the lsass client and the lsass server for each of the lsass server interfaces – the UNIX id mapper interface and the GSS NTLM interface.
Initially, we hand-marshalled these IPC constructs, but as the system grew more sophisticated, the number of hand-marshalled functions grew to the point, that adding a new function got to be tedious. So Brian Koropoff, with his extensive background in compiler and language design, decided to build a data-driven (think idl-like) runtime engine for client-server systems. This is lwmsg.
lwmsg allows you to specify function definitions as request-response messages. A remote procedure call function comprises of a request message and a pair of response messages (on SUCCESS and FAILURE). What is so compelling about lwmsg is that you can specify a extensive class of C datatypes to marshall across the wire. Pretty much the entire DCE/RPC idl can be represented using lwmsg specifications. A calling client-server program specifies its “idl” as a set of global arrays and the light-weight run-time now handles the entire marshalling and unmarshalling for a calling program.
LWIS is using lwmsg in three subsystems – the lsass subsystem, the netlogon subsystem and our newest lsmb subsystem. lwmsg builds very easily, has no dependencies and we’ve just released it on trunk. Its licensed under the LGPL so feel free to get it a whirl.
