Lines Matching +full:client +full:- +full:id
2 .\" Must use -- tbl -- with this one
51 One program may deal with high-level applications such as file system
52 access control and locking. The other may deal with low-level file
53 IO and have procedures like "read" and "write". A client machine of
55 the two programs of the service on behalf of some user on the client
62 procedure in some well-specified location (such as a result
65 procedure are extracted from the well-specified location, and the
86 may choose to have RPC calls be asynchronous, so that the client may
105 is own retransmission and time-out policy as the RPC layer does not
113 application retransmits RPC messages after short time-outs, the only
119 client and not regrant them in order to insure some degree of
120 execute-at-most-once semantics. A server can do this by taking
121 advantage of the transaction ID that is packaged with every RPC
122 request. The main use of this transaction is by the client RPC layer
123 in matching replies to requests. However, a client application may
124 choose to reuse its previous transaction ID when retransmitting a
126 remember this ID after granting a request and not regrant requests
127 with the same ID in order to achieve some degree of
128 execute-at-most-once semantics. The server is not allowed to examine
129 this ID in any other way except as a test for equality.
135 connection-oriented protocol like TCP is used, an application still
136 needs time-outs and reconnection to handle server crashes.
138 There are other possibilities for transports besides datagram- or
139 connection-oriented protocols. For example, a request-reply protocol
149 The act of binding a client to a service is NOT part of the remote
151 is left up to some higher-level software. (The software may use RPC
154 Implementors should think of the RPC protocol as the jump-subroutine
162 The RPC protocol provides the fields necessary for a client to
163 identify itself to a service and vice-versa. Security and access
181 Provisions for authenticating the caller to service and vice-versa.
184 worth supporting because of protocol roll-over errors, implementation
239 disagreement about the protocol between client and service.)
243 Provisions for authentication of caller to service and vice-versa are
294 0 - 1fffffff&Defined by Sun
295 20000000 - 3fffffff&Defined by user
296 40000000 - 5fffffff&Transient
297 60000000 - 7fffffff&Reserved
298 80000000 - 9fffffff&Reserved
299 a0000000 - bfffffff&Reserved
300 c0000000 - dfffffff&Reserved
301 e0000000 - ffffffff&Reserved
317 However, the protocol itself is a message-passing protocol with which
318 other (non-RPC) protocols can be implemented. Sun currently uses, or
320 (non-RPC) protocols: batching (or pipelining) and broadcast RPC.
325 Batching allows a client to send an arbitrarily large sequence of
328 batching, the client never waits for a reply from the server, and the
335 In broadcast RPC-based protocols, the client sends a broadcast packet
337 unreliable, packet-based protocols (like UDP/IP) as its transports.
348 description language. The message is defined in a top-down style.
401 AUTH_REJECTEDCRED = 2, /* \fIclient must begin new session \fP*/
414 * followed by a two-armed discriminated union. The union's
420 * service side cannot treat this id as any type of sequence
496 /* \fIprocedure-specific results start here\fP */
541 open-ended to the rest of the RPC protocol. This section defines
577 is an arbitrary ID which the caller machine may
582 is the caller's effective user ID. The
584 is the caller's effective group ID. The
623 The naming is too UNIX-system oriented.
645 For example, a UNIX user at Sun with a user ID of 515 might be
650 user ID 515. However, there may be another user on another
652 that, by coincidence, happens to have the same user ID. To insure
659 a one-to-one correspondence between naming methods and operating
668 so the server can validate the client's credential (and
669 vice-versa). The contents of this verifier is primarily an
671 it is close to what the real time is, then the client must have
672 encrypted it correctly. The only way the client could encrypt it
674 if the client knows the conversation key, then it must be the real
675 client.
677 The conversation key is a DES [5] key which the client generates
681 authentication is Diffie-Hellman [3] with 192-bit keys. The
684 The client and the server need the same notion of the current time
686 cannot be guaranteed, then client can synchronize with the server
690 The way a server determines if a client timestamp is valid is
695 same client.
700 of the client's timestamp plus what is known as the client's
701 "window". The "window" is a number the client passes (encrypted)
708 quite easy for the client to send random data in place of the
710 check, the client sends an encrypted item in the first transaction
714 The client too must check the verifier returned from the server to
715 be sure it is legitimate. The server sends back to the client the
716 encrypted timestamp it received from the client, minus one second.
717 If the client gets anything different than this, it will reject it.
723 subsystem returns in its verifier to the client an integer
724 "nickname" which the client may use in its further transactions
727 server which stores for each client its netname, decrypted DES key
730 Though they originally were synchronized, the client's and server's
731 clocks can get out of sync again. When this happens the client RPC
736 A client may still get the
741 it wants. A client should resend its original credential in this
752 * There are two kinds of credentials: one in which the client uses
755 * client must use its fullname in its first transaction with the
756 * server, in which the server will return to the client its
757 * nickname. The client may use its nickname in all further
769 * A 64-bit block of encrypted DES data
783 * A fullname contains the network name of the client, an encrypted
796 string name<MAXNETNAMELEN>; /* \fIname of client \f(CW*/
825 * Verifier: client variety
831 * \f(CWadv_timestamp; \fP-- one DES block
832 * \f(CWadc_fullname.window; \fP-- one half DES block
833 * \f(CWadv_winverf; \fP-- one half DES block
848 * The server returns (encrypted) the same timestamp the client
849 * gave it minus one second. It also tells the client its nickname
855 unsigned int adv_nickname; /* \fInew nickname for client \fP*/
860 \&Diffie-Hellman Encryption
944 short-lived.
946 The conversation key is encrypted using 56-bit DES keys, yet the
948 selected from the common key as follows. The middle-most 8-bytes
950 lower order bit of each byte, producing a 56-bit key with 8 bits of
964 fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
969 is the last fragment) and a 31-bit unsigned binary value which is the
971 highest-order bit of the header; the length is the 31 low-order bits.
978 Just as there was a need to describe the XDR data-types in a formal
980 on these XDR data-types in a formal language as well. We use the RPC
999 void
1004 * Ping the caller, return the round-trip time
1005 * (in microseconds). Returns -1 if the operation
1019 void
1037 computing round-trip times from the client to the server and back
1040 The second procedure is used for the client to have the server do a
1041 reverse ping operation back to the client, and it returns the amount
1048 for compatibility with old client programs, and as this program
1056 .I program-def
1060 program-def:
1062 version-def
1063 version-def *
1066 version-def:
1068 procedure-def
1069 procedure-def *
1072 procedure-def:
1073 type-specifier identifier "(" type-specifier ")"
1100 transport-specific port numbers. This program makes dynamic binding
1112 broadcast to a given program, the client actually sends its message
1115 specified by the client. When the port mapper gets the reply from
1116 the local service, it sends the reply on back to the client.
1257 via the well-known port mapper's port. The parameters "prog",
1279 Procedure Calls"; XEROX CSL-83-7, October 1983.
1285 Transactions on Information Theory IT-22, November 1976.
1293 [6] Postel, J.; "Transmission Control Protocol - DARPA Internet