Answer

TCP or UDP?

Similarities

DCE remote procedure calls (RPCs) can be made using either TCP/IP or UDP/IP as the underlying network transport. For many applications it doesn't matter which of these two "protocol sequences" ("protseqs" for short) you choose to use because RPCs work basically the same way using either one. For example:

• * Reliability semantics are the same. You may be aware that UDP, a datagram-type communications protocol, is commonly referred to as being an "unreliable network transport", while TCP, a connection-oriented protocol, is described as being a "reliable transport". This is because at the OS level, no attempt is made to detect dropped or out-of-sequence UDP packets, whereas the OS implementation of TCP makes use of sophisticated error-correcting techniques to prevent data loss. This is not an issue for DCE RPCs, however, because DCE essentially adds an error-correcting layer of its own on top of UDP, so the user of DCE RPCs sees a reliable transport. All the UDP error management is done inside the DCE RPC runtime, so the programmer need not worry about it. In terms of reliability semantics, DCE RPCs over UDP and TCP are identical.
  
  * Security: neither protseq is inherently more or less secure than the other when used as a basis for DCE RPCs. Specifically, Kerberos version 5 is used for authentication for both types of RPCs. Data flowing over either protocol can be integrity-protected to prevent tampering (using a cryptographic checksum on each packet), or can be encrypted to prevent eavesdropping (using 56-bit DES encryption).
  
  * Performance: in general, DCE RPC performance over the two protseqs is approximately the same. Certainly there may be some network configurations that favor one protseq over the other (more on this below), but for the most common network topologies, performance is not usually an issue when choosing a protseq.



 
•  

Differences

Given the broad similarities in behavior of DCE RPCs on the two protocol sequences, many applications will behave equally well using either one. However, there are some situations where one protseq is a better choice than the other:

• * Heavily-used servers: TCP uses substantially more OS resources than UDP does and therefore UDP is preferred (often strongly preferred) in environments where servers must handle many simultaneous clients. Overall scalability is much better with UDP. Running out of file descriptors is a real concern for servers that handle many TCP RPCs, for example. (The file-descriptor problem is most serious on Solaris, where the fopen family of standard I/O functions can make use only of file descriptors less than 256 -- so failure to open files via fopen can occur in even a moderately loaded server on Solaris if that server uses TCP. Since Kerberos uses fopen, these failures can cause serious havoc.)
  
  * Failover: since the connection management for UDP RPCs is done by DCE itself, DCE has more control over connection parameters, including timeouts. With TCP, DCE is more at the mercy of the OS with respect to connection management. This can have significant implications when failover is important -- that is, when it is important to quickly defect and bypass a failed replicated server like secd or cdsd. UDP generally provides more consistent and controllable failover characteristics than does TCP.
  
  * Since UDP was the first supported protseq for DCE and since DFS uses UDP exclusively for its kernel-level RPCs, the UDP implementation is probably more mature.
  
  * Debugging: in a development environment where a client or server process may be stopped in a debugger, TCP is preferred. This is because the OS will maintain the TCP connection, but with UDP the DCE peer process may fail because its partner unexpectedly halted in a funny way.
  
  * Network topology: some network configurations, particularly those involving low bandwidth or variable-bandwidth connections, may favor TCP. Some other aspects of the network, for example firewalls, may prefer one of the protseqs over the other. This is an area where you may have to perform controlled experiments in order to determine if any significant differences exist.

All this assumes that the underlying OS implementation of both protseqs is adequate. If on the other hand your OS has a poor UDP implementation, then TCP might be preferred for large applications despite the other factors listed in the above bullets. This is not an issue for AIX or Solaris or for any other UNIX implementation that we are aware of, but it may be a consideration if you must communicate with non-UNIX systems via DCE.


Other Notes

A few more comments and differences:

• * Security protection levels: "call-level" protection (specifically, the rpc_c_protect_level_call parameter in a client's call to rpc_binding_set_auth_info()) is not available over connection-oriented protseqs like TCP. If a client requests call-level protection, the security runtime will actually deliver the next highest protection level that is supported, namely "packet-level" (rpc_c_protect_level_pkt).
  
  * Timeout characteristics: this is an area where DCE's greater control of UDP is apparent. With TCP, the OS controls connection timeouts and you get what you get. However, with UDP you can use the DCE rpc_mgmt_set_com_timeout function to adjust timeouts on a per-binding-handle basis. With default settings, a UDP RPC that's directed to a dead server or to a server on a dead machine will always experience a timeout delay of approximately 35 seconds. With TCP, however, the timeout will be very short (under 1 second) if the TCP module on the server machine is up (e.g. if the server process itself has died), but the timeout can take many minutes if the server's TCP module is unreachable (e.g. the network is broken or the server machine is dead). UDP timeouts are more predictable and controllable than TCP timeouts, but the length of the timeout period may be longer or shorter with TCP, depending on the nature of the failure.
  
  These timeout characteristics can also affect the time it takes for a "context handle rundown procedure" to be invoked if you're using that feature.
  
  * Error codes: in some cases, TCP provides better error codes. For example, if an RPC fails because a server's queue is full, you'll get a "server too busy" error (rpc_s_server_too_busy, code 382312560) if you're using TCP but with UDP you'll just get a generic communications failure error (rpc_s_comm_failure, code 382312470).
  
  * TCP RPCs are subject to transient failures because of "association shutdowns" (rpc_s_assoc_shutdown, code 382312534) when a server is heavily loaded; this condition does not occur with UDP RPCs.



 
•  

You can use the RPC_SUPPORTED_PROTSEQS environment variable to limit a process to one protseq or the other. Also, depending on your platform, you may be able to control UDP timeouts via the RPC_BINDING_TIMEOUT environment variable. See our page on DCE environment variables for more details about these variables.


Migration: Converting an Existing Cell

Note that if you want to modify a cell that has been using both protocols such that it begins to use only one of the two protocols, you will have to do some work in addition to just setting RPC_SUPPORTED_PROTSEQS. Some items to consider are:

• * pe_site and cds_cache.wan files. Normally your /opt/dcelocal/etc/security/pe_site files on all machines will specify both TCP and UDP bindings to one or more security servers; you should edit those files and remove the binding information for the protseq that you're eliminating. The same comment may apply to your /opt/dcelocal/var/adm/directory/cds/cds_cache.wan file. Both files are just short ASCII text files.
  
  * You should remove the endpoint map database /opt/dcelocal/var/dced/Ep.db when DCE is down (If that database contains endpoints for protseqs that dced no longer supports because of your RPC_SUPPORTED_PROTSEQS setting, then dced will probably fail to restart.)
  
  * Probably you should clear your local CDS client cache too.
  
  * Binding information in CDS server entries. Any existing CDS entries may contain binding information for both protseqs; use the dcecp rpcentry unexport command to remove binding information for the protseq that you want to exclude. (If you don't do this, then clients may sometimes attempt to contact servers via the now-unused protocol, which can cause delays in binding to the servers.)
  
  * Hard-coded protseqs in idl files and C programs, perhaps to specify use of well-known endpoints or to locate servers via string bindings. If you have written applications in which protseq string names are embedded, you may have to modify them.