As per Relevance of the word transport, we have this rfc below:
Network Working Group R.
Request for Comments: 1833 Sun
Category: Standards Track August 1995
Binding Protocols for ONC RPC Version 2
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes the binding protocols used in
with the ONC Remote Procedure Call (ONC RPC Version 2) protocols
TABLE OF
1. Introduction 1
2. RPCBIND Program Protocol 2
2.1 RPCBIND Protocol Specification (in RPC Language) 3
2.2 RPCBIND Operation 9
2.2.1 RPCBIND Version 3 9
2.2.2 RPCBIND, Version 4 10
3. Port Mapper Program Protocol 11
3.1 Port Mapper Protocol Specification (in RPC Language) 11
3.2 Port Mapper Operation 13
References 14
Security Considerations 14
Author's Address 14
1.
This document specifies the binding protocols used in
with ONC RPC Version 2. As a prerequisite, the reader is expected
be familiar with [1] and [2] which describe the ONC RPC Version 2
XDR (eXternal Data Representation) protocols
An RPC service is identified by its RPC program number,
number, and the transport address where it may be reached.
transport address, in turn, consists of a network address and
transport selector. In the case of a service available over TCP/
or UDP/IP, the network address will be an IP address, and
transport selector will be a TCP or UDP port number
Srinivasan Standards Track [Page 1]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
A client program needs to know the RPC program number,
number, and the transport address corresponding to a service in
to utilize the service. Of these, the RPC program number and
number are usually built into the client program, as part of
service definition. The network address component of the
address is usually available in a name service, or is given as
parameter to the client program. The transport selector (ie.,
TCP or UDP port) is usually determined dynamically, and varies
each invocation of the service. Server programs allocate a
address, and register it with a well-known lookup service (well-
because it uses a fixed transport selector, and resides at the
network address as the server). Client programs consult the
service in order to obtain the server's transport address
Such a lookup service is very desirable because the range of well
known transport selectors is very small for some transports and
number of services is potentially very large. By running only
lookup service on a well-known transport selector, the
addresses of other remote programs can be ascertained by querying
lookup service
This document describes three versions of a lookup service, all
which use the same RPC program number (100000). They all use
111 over TCP and UDP transports. Versions 3 and 4 are described
Section 2 ("RPCBIND Program Protocol"). Version 2 is described
Section 3 ("Port Mapper Program Protocol").
The distinguishing characteristic of RPCBIND (versions 3 and 4)
that this protocol uses a transport-independent format for
transport address, known as the universal address format. An
in universal address format is an ASCII string representation of
transport dependent address. String representation of
corresponding to a transport are defined by the addressing
for the transport. The RPCBIND protocol can be used for binding
RPC clients and servers over any transport
The Port Mapper (version 2), on the other hand, is an older
that is specific to TCP and UDP. It handles TCP and UDP
directly
2. RPCBIND Program
The RPCBIND program maps RPC program and version numbers to
addresses, thus making dynamic binding of remote programs possible
The RPCBIND program is bound to a well-known address of
supported transport, and other programs register their
allocated transport address with it. The RPCBIND program then
Srinivasan Standards Track [Page 2]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
those addresses publicly available
The RPCBIND program also aids in broadcast RPC. A given RPC
will usually have different transport address bindings on
machines, so there is no way to directly broadcast to all of
programs. The RPCBIND program, however, does have a well-
address. So, to broadcast to a given program, the client
sends its message to the RPCBIND program located at the
address. Each instance of the RPCBIND program that picks up
broadcast then calls the local service specified by the client.
the RPCBIND program gets the reply from the local service, it
the reply back to the client
2.1 RPCBIND Protocol Specification (in RPC Language
/*
* rpcb_prot.
* rpcbind protocol, versions 3 and 4, in RPC
*/
/*
* rpcbind address for TCP/
*/
const RPCB_PORT = 111;
/*
* A mapping of (program, version, network ID) to
*
* The network identifier (r_netid):
* This is a string that represents a local identification for
* network. This is defined by a system administrator based on
* conventions, and cannot be depended on to have the same value
* every system
*/
struct rpcb {
unsigned long r_prog; /* program number */
unsigned long r_vers; /* version number */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
string r_owner<>; /* owner of this service */
};
struct rp__list {
rpcb rpcb_map
struct rp__list *rpcb_next
};
Srinivasan Standards Track [Page 3]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
typedef rp__list *rpcblist_ptr; /* results of RPCBPROC_DUMP */
/*
* Arguments of remote
*/
struct rpcb_rmtcallargs {
unsigned long prog; /* program number */
unsigned long vers; /* version number */
unsigned long proc; /* procedure number */
opaque args<>; /* argument */
};
/*
* Results of the remote
*/
struct rpcb_rmtcallres {
string addr<>; /* remote universal address */
opaque results<>; /* result */
};
/*
* rpcb_entry contains a merged address of a service on a
* transport, plus associated netconfig information. A list
* rpcb_entry items is returned by RPCBPROC_GETADDRLIST. The
* and values used for the r_nc_* fields are given below
*
* The network identifier (r_nc_netid):
* This is a string that represents a local identification for
* network. This is defined by a system administrator based
* local conventions, and cannot be depended on to have the
* value on every system
*
* Transport semantics (r_nc_semantics):
* This represents the type of transport, and has the following values
* NC_TPI_CLTS (1)
* NC_TPI_COTS (2) Connection
* NC_TPI_COTS_ORD (3) Connection oriented with graceful
* NC_TPI_RAW (4) Raw
*
* Protocol family (r_nc_protofmly):
* This identifies the family to which the protocol belongs.
* following values are defined
* NC_NOPROTOFMLY "-"
* NC_LOOPBACK "loopback
Srinivasan Standards Track [Page 4]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
* NC_INET "inet
* NC_IMPLINK "implink
* NC_PUP "pup
* NC_CHAOS "chaos
* NC_NS "ns
* NC_NBS "nbs
* NC_ECMA "ecma
* NC_DATAKIT "datakit
* NC_CCITT "ccitt
* NC_SNA "sna
* NC_DECNET "decnet
* NC_DLI "dli
* NC_LAT "lat
* NC_HYLINK "hylink
* NC_APPLETALK "appletalk
* NC_NIT "nit
* NC_IEEE802 "ieee802"
* NC_OSI "osi
* NC_X25 "x25"
* NC_OSINET "osinet
* NC_GOSIP "gosip
*
* Protocol name (r_nc_proto):
* This identifies a protocol within a family. The following
* currently defined
* NC_NOPROTO "-"
* NC_TCP "tcp
* NC_UDP "udp
* NC_ICMP "icmp
*/
struct rpcb_entry {
string r_maddr<>; /* merged address of service */
string r_nc_netid<>; /* netid field */
unsigned long r_nc_semantics; /* semantics of transport */
string r_nc_protofmly<>; /* protocol family */
string r_nc_proto<>; /* protocol name */
};
/*
* A list of addresses supported by a service
*/
struct rpcb_entry_list {
rpcb_entry rpcb_entry_map
struct rpcb_entry_list *rpcb_entry_next
};
typedef rpcb_entry_list *rpcb_entry_list_ptr
Srinivasan Standards Track [Page 5]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
/*
* rpcbind
*/
const rpcb_highproc_2 = RPCBPROC_CALLIT
const rpcb_highproc_3 = RPCBPROC_TADDR2UADDR
const rpcb_highproc_4 = RPCBPROC_GETSTAT
const RPCBSTAT_HIGHPROC = 13; /* # of procs in rpcbind V4 plus one */
const RPCBVERS_STAT = 3; /* provide only for rpcbind V2, V3 and V4 */
const RPCBVERS_4_STAT = 2;
const RPCBVERS_3_STAT = 1;
const RPCBVERS_2_STAT = 0;
/* Link list of all the stats about getport and getaddr */
struct rpcbs_addrlist {
unsigned long prog
unsigned long vers
int success
int failure
string netid<>;
struct rpcbs_addrlist *next
};
/* Link list of all the stats about rmtcall */
struct rpcbs_rmtcalllist {
unsigned long prog
unsigned long vers
unsigned long proc
int success
int failure
int indirect; /* whether callit or indirect */
string netid<>;
struct rpcbs_rmtcalllist *next
};
typedef int rpcbs_proc[RPCBSTAT_HIGHPROC];
typedef rpcbs_addrlist *rpcbs_addrlist_ptr
typedef rpcbs_rmtcalllist *rpcbs_rmtcalllist_ptr
struct rpcb_stat {
rpcbs_proc info
int setinfo
int unsetinfo
rpcbs_addrlist_ptr addrinfo
rpcbs_rmtcalllist_ptr rmtinfo
};
Srinivasan Standards Track [Page 6]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
/*
* One rpcb_stat structure is returned for each version of
* being monitored
*/
typedef rpcb_stat rpcb_stat_byvers[RPCBVERS_STAT];
/*
* netbuf structure, used to store the transport specific form
* a universal transport address
*/
struct netbuf {
unsigned int maxlen
opaque buf<>;
};
/*
* rpcbind
*/
program RPCBPROG {
version RPCBVERS {
RPCBPROC_SET(rpcb) = 1;
RPCBPROC_UNSET(rpcb) = 2;
RPCBPROC_GETADDR(rpcb) = 3;
rpcblist_
RPCBPROC_DUMP(void) = 4;
rpcb_
RPCBPROC_CALLIT(rpcb_rmtcallargs) = 5;
unsigned
RPCBPROC_GETTIME(void) = 6;
RPCBPROC_UADDR2TADDR(string) = 7;
RPCBPROC_TADDR2UADDR(netbuf) = 8;
} = 3;
Srinivasan Standards Track [Page 7]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
version RPCBVERS4 {
RPCBPROC_SET(rpcb) = 1;
RPCBPROC_UNSET(rpcb) = 2;
RPCBPROC_GETADDR(rpcb) = 3;
rpcblist_
RPCBPROC_DUMP(void) = 4;
/*
* NOTE: RPCBPROC_BCAST has the same functionality as CALLIT
* the new name is intended to indicate that
* procedure should be used for broadcast RPC,
* RPCBPROC_INDIRECT should be used for indirect calls
*/
rpcb_
RPCBPROC_BCAST(rpcb_rmtcallargs) = RPCBPROC_CALLIT
unsigned
RPCBPROC_GETTIME(void) = 6;
RPCBPROC_UADDR2TADDR(string) = 7;
RPCBPROC_TADDR2UADDR(netbuf) = 8;
RPCBPROC_GETVERSADDR(rpcb) = 9;
rpcb_
RPCBPROC_INDIRECT(rpcb_rmtcallargs) = 10;
rpcb_entry_list_
RPCBPROC_GETADDRLIST(rpcb) = 11;
rpcb_stat_
RPCBPROC_GETSTAT(void) = 12;
} = 4;
} = 100000;
Srinivasan Standards Track [Page 8]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
2.2 RPCBIND
RPCBIND is contacted by way of an assigned address specific to
transport being used. For TCP/IP and UDP/IP, for example, it is
number 111. Each transport has such an assigned, well-known address
The following is a description of each of the procedures supported
RPCBIND
2.2.1 RPCBIND Version 3
RPCBPROC_SET
When a program first becomes available on a machine, it
itself with RPCBIND running on the same machine. The program
its program number "r_prog", version number "r_vers",
identifier "r_netid", universal address "r_addr", and the owner
the service "r_owner". The procedure returns a boolean
whose value is TRUE if the procedure successfully established
mapping and FALSE otherwise. The procedure refuses to establish
mapping if one already exists for the ordered set ("r_prog",
"r_vers", "r_netid"). Note that neither "r_netid" nor "r_addr"
be NULL, and that "r_netid" should be a valid network identifier
the machine making the call
RPCBPROC_UNSET
When a program becomes unavailable, it should unregister itself
the RPCBIND program on the same machine. The parameters and
have meanings identical to those of RPCBPROC_SET. The mapping of
("r_prog", "r_vers", "r_netid") tuple with "r_addr" is deleted.
"r_netid" is NULL, all mappings specified by the ordered
("r_prog", "r_vers", *) and the corresponding universal addresses
deleted. Only the owner of the service or the super-user is
to unset a service
RPCBPROC_GETADDR
Given a program number "r_prog", version number "r_vers", and
identifier "r_netid", this procedure returns the universal
on which the program is awaiting call requests. The "r_netid"
of the argument is ignored and the "r_netid" is inferred from
network identifier of the transport on which the request came in
RPCBPROC_DUMP
This procedure lists all entries in RPCBIND's database.
procedure takes no parameters and returns a list of program, version
network identifier, and universal addresses
Srinivasan Standards Track [Page 9]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
RPCBPROC_CALLIT
This procedure allows a caller to call another remote procedure
the same machine without knowing the remote procedure's
address. It is intended for supporting broadcasts to
remote programs via RPCBIND's universal address. The
"prog", "vers", "proc", and args are the program number,
number, procedure number, and parameters of the remote procedure
Note - This procedure only sends a response if the procedure
successfully executed and is silent (no response) otherwise
The procedure returns the remote program's universal address, and
results of the remote procedure
RPCBPROC_GETTIME
This procedure returns the local time on its own machine in
since the midnight of the First day of January, 1970.
RPCBPROC_UADDR2TADDR
This procedure converts universal addresses to transport
addresses
RPCBPROC_TADDR2UADDR
This procedure converts transport specific addresses to
addresses
2.2.2 RPCBIND, Version 4
Version 4 of the RPCBIND protocol includes all of the
procedures, and adds several additional ones
RPCBPROC_BCAST
This procedure is identical to the version 3 RPCBPROC_
procedure. The new name indicates that the procedure should be
for broadcast RPCs only. RPCBPROC_INDIRECT, defined below, should
used for indirect RPC calls
RPCBPROC_GETVERSADDR
This procedure is similar to RPCBPROC_GETADDR. The difference is
"r_vers" field of the rpcb structure can be used to specify
version of interest. If that version is not registered, no
is returned
Srinivasan Standards Track [Page 10]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
RPCBPROC_INDIRECT
Similar to RPCBPROC_CALLIT. Instead of being silent about
(such as the program not being registered on the system),
procedure returns an indication of the error. This procedure
not be used for broadcast RPC. It is intended to be used
indirect RPC calls only
RPCBPROC_GETADDRLIST
This procedure returns a list of addresses for the given rpcb entry
The client may be able use the results to determine
transports that it can use to communicate with the server
RPCBPROC_GETSTAT
This procedure returns statistics on the activity of the
server. The information lists the number and kind of requests
server has received
Note - All procedures except RPCBPROC_SET and RPCBPROC_UNSET can
called by clients running on a machine other than a machine on
RPCBIND is running. RPCBIND only accepts RPCBPROC_SET
RPCBPROC_UNSET requests by clients running on the same machine as
RPCBIND program
3. Port Mapper Program
The port mapper program maps RPC program and version numbers
transport- specific port numbers. This program makes dynamic
of remote programs possible. The port mapper protocol differs
the newer RPCBIND protocols in that it is transport specific in
address handling
3.1 Port Mapper Protocol Specification (in RPC Language
const PMAP_PORT = 111; /* portmapper port number */
A mapping of (program, version, protocol) to port number
struct mapping {
unsigned int prog
unsigned int vers
unsigned int prot
unsigned int port
};
Srinivasan Standards Track [Page 11]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
Supported values for the "prot" field
const IPPROTO_TCP = 6; /* protocol number for TCP/IP */
const IPPROTO_UDP = 17; /* protocol number for UDP/IP */
A list of mappings
struct *pmaplist {
mapping map
pmaplist next
};
Arguments to callit
struct call_args {
unsigned int prog
unsigned int vers
unsigned int proc
opaque args<>;
};
Results of callit
struct call_result {
unsigned int port
opaque res<>;
};
Port mapper procedures
program PMAP_PROG {
version PMAP_VERS {
PMAPPROC_NULL(void) = 0;
PMAPPROC_SET(mapping) = 1;
PMAPPROC_UNSET(mapping) = 2;
unsigned
PMAPPROC_GETPORT(mapping) = 3;
PMAPPROC_DUMP(void) = 4;
call_
Srinivasan Standards Track [Page 12]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
PMAPPROC_CALLIT(call_args) = 5;
} = 2;
} = 100000;
3.2 Port Mapper
The portmapper program currently supports two protocols (UDP
TCP). The portmapper is contacted by talking to it on assigned
number 111 (SUNRPC) on either of these protocols
The following is a description of each of the portmapper procedures
PMAPPROC_NULL
This procedure does no work. By convention, procedure zero of
protocol takes no parameters and returns no results
PMAPPROC_SET
When a program first becomes available on a machine, it
itself with the port mapper program on the same machine. The
passes its program number "prog", version number "vers",
protocol number "prot", and the port "port" on which it
service request. The procedure returns a boolean reply whose
is "TRUE" if the procedure successfully established the mapping
"FALSE" otherwise. The procedure refuses to establish a mapping
one already exists for the tuple "(prog, vers, prot)".
PMAPPROC_UNSET
When a program becomes unavailable, it should unregister itself
the port mapper program on the same machine. The parameters
results have meanings identical to those of "PMAPPROC_SET".
protocol and port number fields of the argument are ignored
PMAPPROC_GETPORT
Given a program number "prog", version number "vers", and
protocol number "prot", this procedure returns the port number
which the program is awaiting call requests. A port value of
means the program has not been registered. The "port" field of
argument is ignored
PMAPPROC_DUMP
This procedure enumerates all entries in the port mapper's database
The procedure takes no parameters and returns a list of program
version, protocol, and port values
Srinivasan Standards Track [Page 13]
RFC 1833 Binding Protocols for ONC RPC Version 2 August 1995
PMAPPROC_CALLIT
This procedure allows a client to call another remote procedure
the same machine without knowing the remote procedure's port number
It is intended for supporting broadcasts to arbitrary remote
via the well-known port mapper's port. The parameters "prog",
"vers", "proc", and the bytes of "args" are the program number
version number, procedure number, and parameters of the
procedure. Note
(1) This procedure only sends a reply if the procedure
successfully executed and is silent (no reply) otherwise
(2) The port mapper communicates with the remote program using
only
The procedure returns the remote program's port number, and the
is the reply of the remote procedure
[1] Srinivasan, R., "Remote Procedure Call Protocol Version 2",
RFC 1831, Sun Microsystems, Inc., August 1995.
[2] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, Sun Microsystems, Inc., August 1995.
Security
Security issues are not discussed in this memo
Author's
Raj
Sun Microsystems, Inc
ONC
2550 Garcia
M/S MTV-5-40
Mountain View, CA 94043
Phone: 415-336-2478
Fax: 415-336-6015
EMail: raj@eng.sun.
Srinivasan Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
