5: Distributed Computing Environment / Remote Procedure Calls

DCE/RPC is an extremely impressive means to call procedures from one application in another application, without having to know about what computer the other application is running on. The usual underlying concerns of a Remote Procedure Call system, such as how, where, who, security and encryption are all hidden behind an extremely well-defined interface. The only limitations are that the architecture behind DCE/RPC has its roots in static programming languages like c (hence DCOM and SOAP, which provide more object-orientated semantics and dynamic data structures, respectively)

The significant differences between SOAP and DCE/RPC are that SOAP is a relatively immature IPC mechanism which lacks proper security and authentication; and that SOAP provides the means to fully decode the function call's arguments at run-time, whilst the format of the function call arguments in DCE/RPC are well-defined in Interface Definition Language (IDL) format, they are hard-coded (compiled) into the client and server applications and are not transferred at run-time.

ONC/RPC is similar to DCE/RPC. Except that... Sun's ONC/RPC's offerings pale into insignificance compared to DCE/RPC's capabilities. DCE/RPC can negotiate the Data Representation, Transport, Security, Interface (it has Version Control). Sun's ONC/RPC is restricted to XDR for its Data Format, UDP and TCP, and GSS/API for its security. Additionally, XDR is has more restrictions on the data structures it can handle than DCE/RPC's default Data Representation, NDR (Network Data Representation).

5.1: History

DCE/RPC has a long history. It started off life with Apollo, which was later acquired by Hewlett Packard. DCE/RPC was originally called Network Computing Architecture - NCA 1.0. It was only available over UDP. Later, it became clear that NCA would need to move to TCP and there was also a requirement to run it on DECnet 3.0, so it was redesigned to Network Computing System - NCS 2.0. NCS 2.0 was then submitted to The Open Group, and it became Distributed Computing Environment / Remote Procedure Calls - DCE/RPC.

Microsoft, at some point, contacted The Open Group, wishing to license DCE/RPC. The Open Group's charter mandated at the time that they charge USD $20 per seat. Clearly, Microsoft considered this, in light of their expected market impact, and decided to reimplement DCE/RPC themselves, as MSRPC. It is no coincidence that one of the key founders of Apollo is still working for Microsoft.

5.2: DCE/RPC Protocols

TODO: expand / rewrite

DCE/RPC can use a surprisingly large number of protocols as its transport. There follows a short list of the known available protocols:

  • TCP/IP
  • UDP/IP
  • IPX/SPX
  • NetBIOS
  • NETBEUI
  • HTTP
  • DECnet 3.0
  • SMB

    • 5.3: Commonly-known DCE/RPC Services

    TODO: expand / rewrite

    The services that are available over DCE/RPC are too numerous to mention all of them here, particularly as DCE/RPC is used as the underlying mechanism behind DCOM. A list of the services that have been implemented in Samba TNG are available in the section on NT Domains Architecture.

    The other most popularly known DCE/RPC-based services and programs are Exchange (and Outlook), as MAPI is available over DCE/RPC, and MS-SQL 7 and MS-SQL 2000. Even Microsoft's DFS and WINS Services have a DCE/RPC Administrative Interface.

    There is one other DCE/RPC Service that is worth mentioning: it may come as a surprise to some to know that the difference between DCE/DFS and AFS (Andrew File System) is only that DCE/DFS uses DCE/RPC, whilst AFS uses its own in-built RPC mechanism. Additionally, DCE/RPC specifically had a pipe mechanism added to it to cope with the transfer of massive data streams. DCE/RPC pipes was essentially added to deal with large file transfers using DCE/DFS. [TODO: more detail on this from s.tat)

    5.4: DCE/RPC Security

    DCE/RPC is designed to hide the details of the security mechanism from the user. Known security mechanisms include:
  • DCE
  • GSSAPI
  • Kerberos
  • NTLMSSP
    • This last security protocol is only available in MSRPC, which is a serious omission that guarantees that DCE/RPC will remain in the most obscure of realms and echelons of the Computing World. The addition of NTLMSSP security, along with the necessary linkage to a Windows NT / Samba TNG Domain environment, would give DCE/RPC a new lease of life. However, it's not quite as simple as that: the other missing component is that DCE/RPC must have the SMB transport added, too.