The following table shows these basic tasks integrated with the additional tasks required to implement an RPC that provides character and code set interoperability.
Tasks of an Internationalized RPC Application
| Client Tasks | Server Tasks |
| 1. Set locale | |
| 2. Select network protocols | |
| 3. Register RPC interfaces | |
| 4. Advertise RPC interfaces and objects in the namespace | |
| 5. Get supported code sets and register them in the namespace | |
| 6. Listen for calls | |
| 7. Set locale | |
| 8. Establish character and code sets evaluation routine | |
| 9. Find compatible servers that offer the procedures | |
| 10. Call the remote procedure | |
| 11. Establish a binding relationship with the server | |
| 12. Get code set tags from binding handle | |
| 13. Calculate buffer size for possible conversion of input arguments from local to network code set | |
| 14. Convert input arguments from local to network code set (if necessary) | |
| 15. Marshall input arguments | |
| 16. Transmit arguments to the server's runtime | |
| 17. Receive call | |
| 18. Get code set tags sent from client | |
| 19. Calculate buffer size for possible conversion of input arguments from network to local code set | |
| 20. Unmarshal input arguments | |
| 21. Convert input arguments from network to local code set (if necessary) | |
| 22. Locate and invoke the called procedure | |
| 23. Execute the remote procedure | |
| 24. Calculate buffer size for possible conversion of output arguments from local to network code set | |
| 25. Convert output arguments from local to network code set (if necessary) | |
| 26. Marshall output arguments and return value | |
| 27. Transmit results to the client's runtime | |
| 28. Remove code set information from namespace on exit | |
| 29. Receive results | |
| 30. Calculate buffer size for possible conversion of output arguments from network to local code set | |
| 31. Unmarshal output arguments | |
| 32. Convert output arguments from network to local code set (if necessary) | |
| 33. Pass to the calling code the results and return control to it |
1. Both client and server invoke a platform-dependent function to set their locale during initialization. This step establishes the client's and the server's local character and code set; that is, the character and code set currently in use by processes on the client host and processes on the server host.
2. The server, as part of its initialization phase, calls a DCE RPC routine that retrieves information about code sets support on the server's host. The RPC routine examines the host's locale environment and its code set registry to determine the host's supported code sets; that is, code sets for which conversion routines exist that processes on the host can use to convert between code sets, if necessary.
The code set registry is a per-host file that contains mappings between string names for the supported code sets and their unique identifiers. OSF assigns the unique identifiers for the code sets and DCE licensees and DCE administrators assign their platform string names for the code sets. The DCE RPC routines for character set and code set interoperability depend upon a code set registry existing on each DCE host. For more information about the code set registry, see the OSF DCE Administration Guide - Introduction and the csrc(8dce) reference page in the OSF DCE Command Reference.
The routine returns a list of the supported code sets to the server; the list consists of each code set's unique identifier.
3. The server next calls a new RPC NSI routine to register the supported code sets information in the name service database. Recall that a server can use the NSI to store its binding information (information about its interfaces, objects, and addresses) into its own namespace entry, called a server entry. The new RPC NSI routine adds the supported code sets information as an attribute that is associated with the server entry, which the server created when it used the NSI export operation to export its binding information into the name service database. Placing the code sets information into the name service database gives RPC clients access to this information.
4. Before it calls the RPC NSI routines that locate a server that offers the desired remote procedure, the client calls a new RPC routine that sets up a character and code sets compatibility evaluation routine.
5. The client calls RPC NSI routines to locate a compatible server. The RPC NSI routines invoke the character and code sets compatibility evaluation routine set up by the client to evaluate potential compatible servers for character and code set compatibility with the client.
6. The evaluation routine imports the server's supported code sets information from the name service database, retrieves the client's supported code sets information from the client host, and compares the two. If the client and the server are using the same local code set - the code set that processes on the host use to encode character data - then no code set conversion is necessary, and no data loss will result.
If client and server are using different local code sets, then it is possible that the server is using a different character set than the client. The client does not want to bind to a server that is using a different character set, since significant data loss would result during character data conversion. Consequently, the evaluation routine uses the server's code set information to determine its supported character sets, and rejects servers using incompatible character sets. For example, if a client is using the Japanese Kanji character set (such as JIS0208), the evaluation routine rejects a server that offers the desired remote procedure but which is using the Korean character set (such as KS C 5601).
If the client and server are character set-compatible, and they support a common code set into which one or the other (or both) can convert, the evaluation routine deems the server to be compatible with the client. The NSI import routines return this server's binding information to the client.
7. The client makes the remote procedure call.
8. A client stub is called, with the character data represented in the local form and in the local code set.
9. Before marshalling the input arguments, the client stub calls a new stub support routine that retrieves code set identifying information that the evaluation routine established in the binding handle.
10. The client stub next calls a new stub support routine that determines, based on the code set identifying information, whether the character data needs to be converted to another code set, and if so, whether the buffer that currently holds the character data in the local form and code set is large enough to hold the data once it is converted. If the routine determines that conversion is necessary and a new buffer is required, it calculates the size of that buffer and returns the value to the client stub.
11. The client stub next calls a new stub support routine that converts, based on the code set identifying information, the character data from the local code set to the appropriate code set to be used to transmit the data over the network to the server (called the network code set).
12. The client stub then marshalls the input arguments and transmits them to the server runtime along with code set identifying information.
13. The server stub is called, with the character data represented in the network form (which is always idl_byte) and in the network code set.
14. The server stub unmarshalls the input arguments.
15. The server stub next calls a new stub support routine that determines, based on the code set identifying information passed in the client call, whether the character data needs to be converted from the network code set to the server's local code set, and if so, whether the buffer that currently holds the character data in the network format and code set is large enough to hold the data once it is converted. If the routine determines that conversion is necessary and a new buffer is required, it calculates the size of that buffer and returns the value to the server stub.
16. The server stub next calls a new stub support routine that converts, based on the code set identifying information, the character data from the code set used on the network to the server's local code set.
17. The server stub invokes the manager routine to execute the remote procedure.
18. Before marshalling the results of the remote procedure (the output arguments and return values), the server calls a new stub support routine to determine whether conversion from the server's local code set is necessary, based on the code set identifying information it received from the client, and whether or not the buffer currently holding the character data is large enough to accommodate the converted data. If a new buffer is required, the stub support routine calculates the size of this new buffer and returns it to the server stub.
19. The server stub next calls a new stub support routine that converts, based on the code set identifying information from the client, the character data from the server's local code set to the network code set.
20. The server stub marshalls the converted output arguments and transmits them to the client runtime along with code set identifying information.
21. The server initialization procedure also contains a call to a new RPC routine that removes the code set information from server entry in the name service database if the server exits or is terminated.
22. The client stub is called, with the character data in network format and code set.
23. The client stub unmarshalls the output arguments.
24. The client stub next calls a new stub support routine that determines, based on the code set identifying information passed by the server, whether the character data needs to be converted from the network code set to the client's local code set, and if so, whether the buffer that currently holds the character data in the network format and code set is large enough to hold the data once it is converted. If the routine determines that conversion is necessary and a new buffer is required, it calculates the size of that buffer and returns the value to the client stub.
25. The client stub next calls a new stub support routine that converts, based on the code set identifying information, the character data from the code set used on the network to the client's local code set.
26. The client stub passes the data to the client in the local format and code set.
Note that the stub conversion routines do not implement code set conversion. Instead, they call POSIX-compliant iconv code set conversion routines, which are part of the local operating system. As a result, if the platform to which DCE is ported does not provide these POSIX conversion routines, DCE applications that run on this platform cannot use the DCE RPC character and code set interoperability features.