Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: Ma Donghui (Eaststone Ma_donghui@263.net)
Translation time: 2001-3-28
Copyright: This translation document can be used for non-commercial use free reprint, but the translation and organizational information of this document must be retained.
Network Working Group Sun Microsystems, Inc.
Request for Comments: 1050 April 1988
Remote process call protocol specification
(RFC1050 --- Remote Procedure Call Protocol Specification)
Summary
Remote Procedure Call enables the program to call the process icon in the remote node to call the local process as convenient. This article is the Chinese version of the remote procedure call protocol specification.
table of Contents
1. Introduction 1
2. Terminology 2
3. RPC model 2
4. Transmission and semantics 2
5. Binds and Collectible Independence 3
6. Certification 4
7. RPC protocol requirements 4
8. RPC Message Protocol 7
9. Certification agreement 10
10. Record the standard 16
11.RPC language 16
Appendix A: Port Map Program Agreement 18
1. Introduction
This document describes a message protocol in the remote procedure call (RPC) package that implements Sun Company. This message protocol is defined by an external data description (XDR) language [9]. This document assumes that the reader is very familiar with XDR, which does not try to demonstrate the benefits of using RPC. Here is a background written by Birrell and Nelson [1] as a background for the RPC.
2. the term
This document discusses these terms for servers, services, procedures, processes, customers, and versions. The server is software that implements network services. Network service is a collection of one or more remote programs. A remote program implements one or more remote processes; the parameters and results of these processes have been archived in a specific program protocol specification (see the example in Appendix A). Network customers are software that emits remote procedures to the service. A server may support more than one version of the remote program so that it is compatible with the changed protocol.
For example, a network file service may consist of two programs. A program handles high-level applications such as file system access control and locking. Another program processes the low-level file I / O, which has a process like "Read" and "Write". The client of the network file service will call the service with the two programs in accordance with the needs of our users.
3. RPC model
The remote process call model is very similar to the local process call model. In the local process call, the caller puts the parameters to be transmitted in a clearly defined location (eg, a result record). Then the caller will transfer the control to the called process, and finally get the return control. At the return point, the result of the called process is removed from a well defined position, and the caller continues.
The remote process call is also similar, and the two processes are logically run together to constitute a control main line. One is a caller process and the other is a server process. That is, the caller process is sent to the server process a call message and waits for (blocking) until the response message is received. The call message contains the parameters of the call being called. The response message contains the results of the called process, and the like. Once the response message is received, the result of the called process will be removed, and the caller will resume. On the server side, a process is in a sleep state to wait for the arrival of the call message. When a call message arrives, the server process takes out the parameters of the called process from the message, calculates the result, sends a response message, and then waits for the next call message.
Note: In this mode, only one of the two processes is activated in two processes. However, this mode is just as an example. The RPC protocol does not limit the implementation of concurrent models, and there may be other methods of implementing concurrent models. For example, an implementation may selecting an RPC call is performed asynchronous, so that the client can do other useful work in the response of the waiting server. Another possibility is to enable the server to create a new task to process the input request so that the server can freely receive other requests.
4. Transmission and semantics
The RPC protocol does not depend on the transfer protocol. That is, the RPC does not care about how the message is passed from one process to another process. This protocol only processes the specifications and messages of the protocol.
It is also necessary to point out that the RPC does not try to implement any reliability, so the application must consider the transport layer protocol in the lower layer of the RPC. If the application knows that he runs on the upper layer of the reliable transport layer like TCP / IP [6], it knows that most of the work that guarantees reliability is already done. On the other hand, if the application runs on the upper layer of the unreliable transport layer like UDP / IP [7], it must implement its own retransmission and timeout strategy, and these service RPC layers are not available.
Because independent of the transport layer, the RPC protocol does not attach special semantics to the remote process. It can be inferred from the transport layer below (but there should be clear definitions). For example, consider the upper layer of RPC running in an unreliable transport layer UDP / IP. If the application retransmits the RPC message after a short timeout, when the response does not receive a response, the only thing it can judge is that the process is not executed or executed. When a response is received, it can infer the process of at least once.
The server may wish to remember the previously allowed request from the client. In order to sure to some extent, only one semantics are only performed, the server no longer re-approves these requests. The server implements this function by using the transaction ID packaged in the RPC request. The main purpose of the transaction is the client's RPC layer to match the response to the request. However, the client application can choose to use its previous transaction ID when retransmit a request. After the server application knows this fact, you can choose to remember this transaction ID after a request, in order to get the semantics that only perform one degrees, the server is no longer re-approved for requests with the same ID. In addition to operations that can be tested, the server is not allowed to check this ID using other methods.
On the other hand, if a reliable transmission such as TCP / IP is used, the application can infer the process from a response message has been executed correctly. However, if it does not receive a response message, it cannot be assumed that the remote process is not executed. Note: Even if you use a connection-oriented protocol like TCP, the application still needs timeout and reconnection features to handle the server crash.
In addition to a datagram or facing the connection-oriented protocol, there is a possibility of other transport layer protocols. For example, a request response protocol such as VMTP [2] may be the most natural transport layer protocol for RPC.
Note: In the sun, RPC is currently implemented in TCP / IP and UDP / IP.
5. Binding and collection independence Bind a client to a service is not part of a remote process call specification. This important and necessary features have left some upper software (this software may use RPC itself, see Appendix A)
The executor should regard the RPC protocol as a jump to the subroutine command ("JSR") on the network; the loader (binders) make JSR available, the loader itself uses JSR to complete its own task. Similarly, the network allows RPC to use RPC to complete its task.
6. Certification
The RPC protocol provides some necessary fields to enable customers to identify itself to the service. In turn, services should also be used to identify themselves to customers. Security and access control mechanisms are based on message authentication. Some different certification protocols are supported. There is a field in the RPC header to point out which authentication protocol used. Information about the more detailed certification protocol is discussed in Article 9 "Certification Agreement".
7. RPC protocol requirements
The RPC protocol must be able to provide the following features:
(1) The only specification of a calling process
(2) Match the rules for respond messages and request messages
(3) Rules for service authentication caller and caller identification services
In addition to the above requirements, it is also necessary to detect the following due to an error due to protocol, implementation, user, and network management:
(1) RPC protocol does not match
(2) Remote program protocol version does not match
(3) Agreement error (such as error specifying process parameters)
(4) Reminary reasons for remote authentication
(5) Other reasons for can't call the desired process
7.1 RPC procedures and processes
RPC call message has three unsigned fields: remote program number, remote program version number, and remote process number. These three fields uniquely identify the process being called. The program number is managed by some major authority (just like Sun). Once the executor has a program number, he can perform his remote program; the first execution is likely to have a version number 1. Because most new protocols have developed into better, more stable, more mature protocols, so the version field in the call message identifies which version of the caller used the protocol. The version number makes it possible to run the old agreement and the new protocol through the same server process.
The process number identifies the process called. These numbers have archived in the protocol specification of a particular program. For example, the file service protocol specification may define its process number 5 as "read", and the process number 12 is defined as "Write".
Just like a remote program agreement may have some changes on some versions. The actual RPC message protocol may also change. Therefore, call messages also have its own RPC version number. This version number is always equal to 2 for RPC described herein.
The response message of the request message has sufficient information to distinguish the following error:
(1) RPC remote implementation should use the second edition of the protocol, the lowest and maximum version number supported by the RPC protocol
Will return.
(2) Remote program is not available in remote systems.
(3) The remote program does not support the requested version number. The minimum and maximum version number supported by the remote program will return.
(4) The process number requested does not exist. (This is always because the caller party or the program is wrong)
(5) Parameters pass to the remote process are useless in the server (this is actually caused by the agreement between the client and the server).
7.2 certification
The server's authentication of the caller and the calibration of the caller is part of the RPC protocol. Call messages There are two authentication fields, certificates, and check messages have an authentication field, ie response check. The RPC protocol specification defines these three fields into opaque types.
ENUM auth_flavor {
Auth_null = 0,
Auth_unix = 1,
Auth_short = 2,
Auth_des = 3
/ * More definitions * /
}
Struct opaque_auth {
Auth_flavor flavor;
Opaque Body <400>
}
With a simple English, any "opaque_auth" structure is incorporated by an "auth_flavor" enumerated type and follows some bytes implemented by the RPC protocol.
The semantics and interpretation of the data contained in the authentication field is individual specified, independent of the authentication protocol specification. (Section 9 defined different certification protocols)
If the authentication parameters are rejected, the response message will contain information that will be rejected.
7.3 Program number assignment
The program number is distributed as a set of hexadecimal 20000000 (decimal 536870912) according to the table below.
0 - 1fffffffffffFffF defined
20000000 - 3FFFFFF. Defined by Sun Company
Temporary 40000000 - 5FFFFFF
60000000 - 7FFFFFF
80000000 - 9FFFFFF Reserved
A0000000 - BFFFFFFF
C0000000 - DFFFFFFF
E0000000 - fffffff
The first group is a range of numbers managed by Shengyang Microsystems (Sun Company). It should be consistent in all places. The second group number ranges to a particular location for a particular location for the application. This range is mainly used to debug new procedures. When an application developed in a place is to pay attention to the public, this app should allocate a number in the first set of numbers. The third group number range is dynamically generated by the application. The final number range group is reserved for future, and is currently not used.
7.4 other uses of RPC protocol
The main purpose of using the RPC protocol is to call remote processes. That is, each call message matches one response message. However, this agreement itself is a messaging protocol, other protocols (non-RPC protocols) can also be implemented through this protocol. Sun is currently using the RPC message protocol for the following two non-RPC protocols, which are batch processing (or pipeline) and broadcast RPC, which will be discussed below, but not detailed.
7.4.1 batch processing
Batch allows customers to send an arbitrary call message sequence to the server; it typically uses a reliable byte stream protocol (like TCP / IP) as its transport layer. At the time of batch, the customer never waits for the server response, and the server does not send a response to the batch request. A batch call sequence is always terminated by legal RPC, which is to refresh the pipe (in certain confirmation).
7.4.2 Broadcast RPC
In the protocol based on the broadcast RPC, the client sends a broadcast packet to the network and then waits for a response. Broadcast RPC uses an unreliable datagram protocol (like UDP / IP) as its transport layer. The server that supports the broadcast protocol only responds after the request is successfully performed. The server will remain silent at an error. Broadcast RPC uses port mapper RPC services to get its semantics. (For more information, please refer to Appendix A)
8. RPC Message Protocol
This section defines the RPC message protocol with an XDR data definition language. These messages are defined in a rigorous style. .
ENUM MSG_TYPE {
Call = 0,
Reply = 1
}
/ *
* The response of calling messages can present two forms;
* The message either accepts or rejected
* /
ENUM reply_stat {msg_accepted = 0,
MSG_DENIED = 1
}
/ *
* If a call message is accepted, the following is the status of trying to call the remote process.
* /
ENUM Accept_stat {
SUCCESS = 0, / * RPC execution success * /
PROG_UNAVAIL = 1, / * Remote No Output Program * /
PROG_MISMATCH = 2, / * Remote does not support version number * /
PROC_UNAVAIL = 3, / * Program does not support process * /
GARBAGE_ARGS = 4 / * procedure cannot explain the parameters * /
}
/ *
* Call message is rejected
* /
ENUM REJECT_STAT {
RPC_MISMATCH = 0, / * RPC version number is not equal to 2 * /
Auth_error = 1 / * Remote Captured caller * /
}
/ *
* Reasons for certification failure
* /
ENUM auth_stat {
Auth_badcred = 1, / * Error Certificate (package is broken) * /
Auth_rejectedcred = 2, / * Customers must start new sessions * /
Auth_badverf = 3, / * Error check (package is broken) * /
Auth_rejectedVerf = 4, / * Checks expired or re-put * /
Auth_tooWeak = 5 / * Declined for security reasons * /
}
/ *
* RPC message
* All messages start with a transaction identifier XID, followed by the two branches of the judgment.
* This combined discrimination is one of the MSG_TYPE equal to two types of messages.
* The XID of the response message always matches the XID that starts calling the message.
* The client uses this field to assemble the received response message and call message,
* The server side uses this field to detect retransmission.
* The server side cannot regard this ID as any type of serial number.
* /
Struct RPC_MSG {
Unsigned int XID;
Union switch (msg_type mtype) {
Case Call:
Call_body cbody;
Case reply:
Reply_body rbody;
}
}
/ *
* RPC requests the entity:
* In version 2 of the RPC Protocol Specification, the RPCVERS field must be equal to 2.
* Fields PROG, VERS, and PROC determine the remote program, and the version number of the program
* And the process called in a remote program. At the end is two authentication parameters
* CRED (authentication certificate) and VERF (authentication check). The following is the parameter of the remote process,
* These parameters are specified by the specific program protocol.
* /
Struct call_body {
Unsigned int rpcvers; / * must be equal to 2 * /
Unsigned int prog;
Unsigned int.
Unsigned int proc;
Opaque_auth CRED;
Opaque_auth Verf;
/ * Specific parameters of the process start from here * /
}
/ *
* RPC request response entity;
* Call message either accept or rejected
* /
Union reply_body switch (reply_stat stat) {
Case msg_accepted:
Accepted_reply deflection;
Case msg_denied:
REJECTED_REPLY RREPLY;
} reply;
/ *
* Response when the server accepts RPC request:
* Even if the request is accepted, there may be an error. * The first field is the authentication check verifier generated by the server, in order to enable the caller to identify the server.
* Next is a discriminating type is the combination of enumeration type accept_stat.
* One branch of Success in the United States is a specific protocol.
* United THE PROG_UNAVAIL, PROC_UNAVAIL and GARBAGE_ARGS
* The branch is empty. The PROG_MISMATCH branch determines the remote support from the server
* The minimum and maximum version number of the program.
* /
Struct ACCEPTED_REPLY {
Opaque_auth Verf;
Union switch_stat stat {
Case Success:
Opaque results [0];
/ *
* Specific process results start here
* /
Case Prog_Mismatch:
Struct {
Unsigned int low;
Unsigned int high;
Mismatch_info;
DEFAULT:
/ *
*air. These conditions include prog_unavail,
* Proc_unavail and garbage_args.
* /
Void;
} reply_data;
}
/ *
* When the server rejects the response when the RPC request:
* Request may be rejected due to two reasons: one is that the server does not run the RPC protocol.
* Compatible with version (rpc_mismatch), the other is the server does not authenticate the caller (auth_error).
* When the RPC version does not match, the server returns the supported minimum and maximum version number.
* Returns the failure state without authentication.
* /
Union rejected_reply switch (reject_stat stat) {
Case rpc_mismatch:
Struct {
Unsigned int low;
Unsigned int high;
Mismatch_info;
Case auth_error:
Auth_stat stat;
}
9. Certification agreement
As mentioned earlier, the authentication parameters are opaque, but the rest of the RPC protocol is adjustable. This section describes the "feature value" that is implemented (or by Sun support) in the sun. Freedom can create new authentication types in other places. The rules of the allocation of the feature value are the same.
9.1 dissemination
Usually the process will call when the caller doesn't know who it or the server does not care about who is the caller. In this case, the certificate, check and the combination of Opaque_auth's combination of Opaque_Auth are "auth_null" in this case. The bytes in the entity of Opaque_Auth are not defined. It is recommended that these OPAQUE lengths are 0.
9.2 UNIX certification
The caller of the remote process may wish to identify itself as in the UNIX system. The value of the certificate discriminant in the RPC call message is "auth_unix". The Opaque entity of these certificates encodes the following structure:
Struct auth_unix {
Unsigned int stamp;
String Machinename <255>
UNSigned int UID;
Unsigned int GID;
Unsigned int GIDS <10>
}
"stamp" is a binary identifier (ID) generated by a caller machine. "Machnename" is the name of the caller machine (such as "Krypton"). "UID" is the calibrator's valid user identifier ID. "GID" is the active group identifier ID of the caller. "GIDS" is a count array containing the caller as a member. The verification of the certificate should be "auth_null" (above-defined) the determined value of the response check message received from the server may be "auth_null" or "auth_short". In the case of "auth_short", the string bytes of the check check is encoded into an opaque structure. This new opaque structure can now be passed to the server instead of the original "auth_unix" feature value certificate. The server retains a buffer to map to the original certificate of the caller (passing through a "auth_short" type response check check check check check. The caller can save the new certificate to save the CPU cycle on the server on the server.
The server may refresh this shorthand opaque structure at any time. If this happens, the remote procedure call message will be rejected due to the authentication error. The reason for failure will be "auth_rejectedcred". At this time, the caller may want to try the original "Auth_unix" certificate type.
9.3 DES certification
UNIX certification encountered the following two main issues:
(1) Naming Too too for UNIX
(2) There is no verification, so the certificate is easy for fake.
DES certification efforts to solve these two problems.
9.3.1 Name
The method of processing the first problem is to locate the caller by replacing the operating system specific integer by using a simple string. This string is the "NetName" or the call name of the caller. In addition to the identification caller, the server does not allow the server to explain the contents of the caller name in any other aspect. Therefore, the network name should be unique to each caller in the Internet.
The DES authentication implementation on each operating system generates a network name to ensure that his network name is unique when the user has visited the remote server. The operating system also knows how to distinguish between users in the local system. Extending this mechanism to some small problems on the network. For example, a UNIX user having a user ID number 515 on Sun may be assigned to the following network name: "Unix.515@sun.com". This network name contains three items to confirm that it is unique. There is only one named domain called "sun.com" on the Internet. In this domain, the user ID is 515 UNIX users only one. However, there may be another user on other operating systems, such as on the VMS, and in the same name domain, happens to the same user ID. In order to ensure that two users are distinguished, we join the operating system name. So a user is "unix.515@sun.com" and the other is "vms.515@sun.com".
The first field is actually a naming method instead of an operating system name. Now just happens to have a pair of one-on-one between the naming method and the operating system. If the world is consistent in naming standards, the first field should be a standard name instead of an operating system name.
9.3.2 DES certification verification
Unlike UNIX certification, DES certification has a check, which allows the server to verify the customer's certificate (vice versa). The content of the check is mainly an encrypted timestamp. The server can decrypt this timestamp. If it approaches the real time, the customer must have correctly encrypt it. The only way that the client can encrypt it is to know the "Session Key" of this RPC session. If the client knows this session key, it is the real client. The session key is a DES key [5] generated by the client, and the server is notified when the first RPC is called. The session key is encrypted by a public key mode in the first transaction. The special public key mode using the DES authentication is Diffie-Hellman [3], which has a key length of 128 bit. This is discussed after the details of this encryption method.
In order to complete the work, the client and server need the same time concept. If the network time synchronization cannot be guaranteed, the client can establish synchronization with the server before starting the session. Perhaps negotiate with the Internet Time Server (Time [4]).
The server determines whether a client timestamp is a bit complicated. For other matters other than the first transaction, the server only checks two things.
(1) This timestamp is stamped by the previous time from the same client.
(2) This timestamp did not expire.
This time stamp is expired if the server time is higher than the client's timestamp and the client's window value (Window). "Window" is a number that the client passes (encrypted) to the server in its first transaction. You can regard it as a survival of the certificate.
The above explains every transaction in addition to the first transaction. In the first transaction, the server only checks that the timestamp has no expire. If all work is all, for the client, send random data will be very easy to replace the timestamp, which will have a lot of success. As an additional check, the client sends a "window check" in the first transaction, which must be equal to the window value to 1, otherwise the server will reject this certificate.
The client must also check the checkstered from the server to determine that the server is legal. The server will send it to the client after the encrypted time received from the client is reduced by one second. If the client gets the data is different from this, it will refuse.
9.3.3 Nickname and clock synchronization
After the first transaction, the server DES certification subsystem has a "nickname" integer in the check-in to the client, and the client can use this nickname in every transaction in the future. Replace its network name, encryption DES key and window. Nickname is more like an index on the server on the server, stores the network name, DES key translation, and window of each client in this table.
Although the clock of the client and the server is synchronized at the beginning, they may make it no synchronization again. When this happens, the client RPC subsystem may get "RPC_Autherror" when it is necessary to synchronize again.
Even if the RPC_AUTHERROR error can be obtained even if it is synchronized with the server. This reason is that the server's nickname form is limited, it can refresh the entry in the table at any time when it needs. In this case, the client should resend its original certificate, and the server will give it a new nickname. If the server crashes, the entry in the nickname table is refreshed, and all clients will have to resend its original certificate.
9.3.4 DES Certification Protocol Specification (Description with XDR Language)
/ *
* There are two certificates: one is a full name network name using it, the other is the client.
* The nickname sent by the server (just an unsigned integer). In the first time with the server,
* The client must use its full name. The server will return to the client it's nickname.
* The client can use its nickname in a server's transaction. Not necessarily to use nicknames,
* But using nicknames will be a wise choice. * /
ENUM Authdes_namekind {
ADN_FULLNAME = 0,
ADN_NICKNAME = 1
}
/ *
* A 64-bit data block encrypted by DES.
* /
Typedef opaque des_block [8];
/ *
* The maximum length of the network username
* /
Const maxnetnamelen = 255;
/ *
* The full name includes a client's network name, a encrypted session key and window. The window is actually
* The survival of the certificate. If the timestamp indicated in the check character, the window has expired after the window,
* Then the server should expire, and do not recognize it. In order to ensure that the request will not be replayed,
* The server should keep the timestamp than the previous timestamp, unless this is the first transaction.
* In the first transaction, the server only checks the window check is a value smaller than the window.
* /
Struct authdes_fullname {
String name
DES_BLOCK key; / * Public key encrypted session key * /
Unsigned int window; / * Encrypted window * /
}
/ *
* A certificate either a full name or a nickname
* /
Union authdes_cred switch (authdes_namekind adc_namekind) {
Case adn_fullname:
Authdes_fullname adc_fullname;
Case adn_nickname:
Unsigned int ADC_NICKNAME;
}
/ *
* Timestamp starts to give time coding from January 1, 1970
* /
Struct timestamp {
Unsigned int seconds; / * second * /
Unsigned int useconds; / * microsecond * /
}
/ *
* Check: the type of client
* The check of the window is only used in the first transaction, in the association with the full name certificate,
* These items are packaged in the following structure before encryption.
*
* struct {
* Adv_timeStamp; - One des block
* ADC_Fullname.window; - One Half des block
* ADV_WINVERF; - One Half Des Block
*}
* This structure uses CBC encryption mode encryption with an input 0 vector
* All other time stamp encryption is encrypted using ECB encryption mode
* /
Struct authdes_verf_clnt {
TimeStamp Adv_TimeStamp; / * Encryption Time Stamp * /
Unsigned int adjinverf; / * Encrypted window check * /
}
/ *
* Check: Server Type
* The server returns this encrypted timestamp and then returns to the client.
* The server also tells the client to its nickname (unexcry), which is already used in future transactions.
* /
Struct authdes_verf_svr {
TimeStamp Adv_timeverf; / * Encrypted Check * /
Unsigned int adjt, new INT Adv_nickname; / * Client new nickname * /
}
9.3.5 Diffie-Hellman Encryption Method
In this mode, there are two constants "proot" and "MODULUS". SUN has selected a specific value for the DES certification protocol:
Const proot = 2;
Const modulus = "B520985FB31FCAF75036701E37D8B857"; / * Hexadecimal * / This mode work is preferably used to explain. Suppose two people "a" and "b" want to send encrypted messages to each other. Therefore, both A and B are randomly generated a "secret" key. This key does not want others to know. The two keys are represented as SK (a) and SK (B). They also publish their "public" key in a public name address store. The public key is calculated from the following manner.
PK (a) = (ProT ** SK (a)) Mod MoDULUS
PK (b) = (ProT ** SK (b)) Mod MoDULUS
"**" symbol indicates the power here. Now A and B can get the "public" key between them without exposing their secret keys. The public key is described here as CK (A, B),
A computer:
CK (a, b) = (pk (b) ** SK (a)) MOD MODULUS
B Computer:
CK (a, b) = (pk (a) ** SK (b)) mod modulus
These two values are equal:
(PK (b) ** SK (a))) MOD MODULUS = (PK (a) ** SK (b)) Mod MoDULUS
We remove the modeling algorithm part of "Mod MoDulus" to simplify.
PK (b) ** SK (a) = pk (a) ** SK (b)
Then, the results obtained by previous B calculations are replaced, and the PK (a) is also made to make such a step.
((ProT ** SK (b)) ** SK (a) = (ProT ** SK (a)) ** SK (B)
This will result in:
ProT ** (SK (a) * SK (b)) = proot ** (SK (a) * SK (b))
The public key CK (A, B) is not used to encrypt the timestamp used in the protocol. It is only used for encrypted session keys, and uses this session key to encrypt the timestamp. The reason for this is because the public key should be used as little as possible to prevent the public key being deciphered. Even if the session key is decipherous, the resulting loss is small because the session is always relatively short.
The session key is encrypted using a 56-bit DES key. And this public key is a 128 bit. In order to reduce the number of bits, the 56 bits are selected from the public key below. Select the most intermediate 8 bytes from the public key, and then add parity to the lowest bit of bitter in each byte. This creates a 56-bit key with 8-bit parity bit.
10. Record the standard of tag
When the RPC message is transmitted at a byte stream protocol (like TCP / IP), it is necessary to define the boundary between a message and another message, which is to detect the error of the user protocol and may be performed on the error. restore. This is called record tag (RM). Sun uses RM / TCP / IP to transfer RPC messages on the TCP stream. An RPC message adapts an RM record.
A record is composed of one or more record pieces. A record piece is a 4-byte head, followed by a piece of pieces of 0 to (2 ** 31) -1 bytes. The byte of the clip head is encoded into an unsigned binary number; like an integer in XDR, the order of the bytes is from high to the end. This number encodes the value of two parts: a part is a Boolean value indicating whether this piece is the last record piece (value 1 indicates that this piece is the last piece), and the other is a 31-bit unsigned binary value. It is the length of this fragment data when the byte count is used. The Boolean value is the highest bit bit of this piece; the length is a low 31 bit. (Note this record specification is not the standard form of XDR!)
11.RPC language
Just like a formal language that needs to define the XDR data type. It also needs to define the process of operating the XDR data type in a formal language. For this purpose, we use the RPC language. It is an extension of XDR language. The following examples are used to describe the essence of this language. Examples of services described in RPC language
Here is an example of a simple ping program.
/ *
* Simple ping program
* /
PROGRAM PING_PROG {
/ *
* Recently and the best version
* /
Version ping_vers_pingback {
Void pingproc_null (void) = 0;
/ *
* Ping This caller, returns round trip time (represented by microseconds). If the operation is timeout,
* Return -1.
* /
INT pingproc_pingback (void) = 1;
} = 2;
/ *
* Original version
* /
Version ping_vers_orig {
Void pingproc_null (void) = 0;
} = 1;
} = 1;
Const ping_vers = 2; / * nearest version * /
In the first version, ping_vers_pingback has two processes pingproc_null and pingproc_pingback. PingProc_null does not require parameters, nor returns a result, but it is useful to calculate the round-trip time back to the client from the client to the client. In a session, any RPC protocol process 0 should have the same semantic, and no type of authentication is required. The client uses the second process to make the server on a reverse ping operation, and it returns the time value (represented by microsecond). The next version ping_vers_orig is the original version of this protocol, which does not contain the pingproc_pingback process. This is useful for compatible client programs. As the program is upgraded, it may be deleted from the entire protocol.
11.1 RPC language specification
In addition to the definition of "program-def", RPC language is the same as the XDR language.
Program-def:
"Program" Identifier "{"
Version-Def
Version-Def *
"}" = "constant"; "
Version-Def:
"Version" Identifier "{"
Procedure-defe
Procedure-def *
"}" = "constant"; "
Procedure-def:
TYPE-Specifier Identifier "(" Type-Specifier ")"
"=" constant ";"
11.2 Precautions for grammar
(1) The following keyword cannot be used as an identifier: "program" and "version";
(2) The version name cannot be more than once within a program definition.
Similarly, the version number cannot be more than once in this program definition.
(3) The process name cannot exceed once within a version definition.
Similarly, the process number does not exceed once in this version definition.
(4) The identifier of the program has the same name space as the symbolic identifier and the type identifier.
(5) Only unsigned constants can be assigned to the programs, versions, and processes.
Appendix A: Port Map Patio Protocol
The port mapper program maps the RPC program and version number to a specific transport port number. This program can dynamically bind the remote program. This approach is required, because the reserved port number is limited, and the potential remote program is much. Run the port mapper on a reserved port number, as long as this port mapper can determine the port number of other remote procedures.
The port mapper is also used in the broadcast RPC. A given RPC program is often bound to different port numbers on different machines, so there is no way to broadcast directly to all of these programs. The port mappier has a fixed port number. To send a broadcast to a given program, the client actually sends the message to the port mapper on the broadcast address. Each port mapper that is broadcast is called by the local service specified by the client. When the port mappier receives the response of the local service, it sends this response to the client.
A.1 Port Map Agreement Specification (with RPC Language)
Const PMAP_Port = 111; / * Port Map of Port Map * /
/ *
* (Program, version, protocol) to port mapping
* /
Struct mapping {
Unsigned int prog;
Unsigned int.
Unsigned int prot;
Unsigned int port;
}
/ *
* "Prot" field supported value
* /
Const ipproto_tcp = 6; / * TCP / IP protocol number * /
Const ipproto_udp = 17; / * UDP / IP protocol number * /
/ *
* A mapping list
* /
Struct * pmaplist {
Mapping Map;
PMaplist next;
}
/ *
* Parameters called
* /
Struct call_args {
Unsigned int prog;
Unsigned int.
Unsigned int proc;
Opaque args <>;
}
/ *
* The result of the call
* /
Struct Call_Result {
Unsigned int port;
Opaque res <>;
}
/ *
* Process of port mapping
* /
Program PMAP_PROG {
Version PMAP_VERS {
Void PMAPPROC_NULL (VOID) = 0;
Bool PMAPPROC_SET (MAPPING) = 1;
Bool PMAPPROC_UNSET (MAPPING) = 2;
Unsigned int pMAPPROC_GETPORT (MAPPING) = 3;
PMaplist PMAPPROC_DUMP (VOID) = 4;
Call_result pMAPROC_CALLIT (CALL_ARGS) = 5;
} = 2;
} = 100000;
A.2 port mappier operation
The port mappier program currently supports two protocols (UDP / IP and TCP / IP). All port mappers are allocated on port 111 in any of these two protocols (SunRPC [8]). Below is a description of each port mappier process:
PMAPPROC_NULL:
This process does not work. According to habits, the No. 0 process of any protocol does not receive parameters and does not return the result.
PMAPPROC_SET:
When a program is available on a machine, it is registered to the port mapper on the same machine.
This program passes its program number "prog", version number "VERS", transport protocol number "prot" and port number
"Port". On the port number of "Port", the program waits for the service. This process returns a Boolean value if the process successfully established a mapping, this value is "true". Otherwise, this value is "false". If there is already "(PROG, VERS, PROT)" tuple, this process refuses to establish a mapping.
PMAPPROC_UNSET:
When the program becomes unavailable, it will log out of itself in the port mapper on the same machine.
Its parameters and results have the same meaning of "pMAPPROC_SET". Agreement and port in the parameter
The field will be ignored.
PMAPPROC_GETPORT:
This process will return when the program number "prog", version number "VERS" and transport protocol "prot" are given.
This program waits for the port number of the call request. Returning a port value means that this program is not registered.
The "Port" field in the parameter will be ignored.
PMAPPROC_DUMP:
This process lists all entries in the port mapper database.
This process does not require parameters, it returns a list of programs, versions, protocols, and port values.
PMAPPROC_CALLIT:
This process allows the caller to call another remote process on the same machine without having to know the port number of this remote process. It supports the broadcast of binary remote programs through a well-known port mapper. The parameters "prog", "VERS", "proc", "args" are the parameters of the program number, version number, the process number, and the remote process, respectively.
note:
(1) If the process is successfully executed, the process only sends a response. Otherwise keep silent (not responding).
(2) Port maps communicate with remote programs only using UDP / IP protocol.
This process returns the result of the port number of the remote program and the result of the remote process.
bibliography
[1] Birrel, A. D., And Nelson, B. J., "Implementing Remote
Procedure Calls, Xerox CSL-83-7, October 1983.
[2] Cheriton, D., "VMTP: VERSATILE Message Transaction Protocol",
Version 0.7, RFC-1045, Stanford University, February 1988.
[3] Diffie & Hellman, "Net Directions in Cryptography", IEEE
Transactions on Information Theory IT-22, November 1976.
[4] Postel, J., And Harrenstien, K., "Time Protocol", RFC-868,
Network Information Center, SRI, May 1983.
[5] National Bureau Of Standards, "Data Encryption Standard",
Federal Information Processing Standards Publication 46,
January 1977.
[6] Postel, J., "Transmission Control Protocol - DARPA INTERNET
Program Protocol Specification, RFC-793; NetWork Information
Center, SRI, September 1981.
[7] Postel, J., "User DataGram Protocol", RFC-768, NetworkInformation Center, SRI, AUGUST 1980.
[8] Reynolds, J. And Postel, J .; "Assigned Numbers", RFC-1010,
Network information center, sri, may 1987.
[9] Sun Microsystems; "XDR: External Data Repesentation
STANDARD ", RFC-1014; Sun Microsystems, June 1987.
RFC1050 --- Remote Procedure Call Protocol Specification Remote Procedure Call Protocol Specification
1
RFC Document Chinese Translation Program
