that allow it to be removed by that entity. With an unrestricted group,
only the latter condition applies.
With a restricted group, a member can only be added by another entity
with the permissions to add other entities. The creator of a group is
given full permissions on a group. A entity adding another entity to a
Cheriton [page 100]
RFC1045 VMTP February 1988
group can only give the entity it adds a subset of its permissions.
With unrestricted groups, any entity can add itself to the group. It
can also add other entities to the group providing the entity is not
marked as immune to such requests. (This is an implementation
restriction that individual entities can impose.)
III.2. VMTP Management Digital Signatures
As mentioned above, the entityId field of the AddToGroup and
RemoveFromGroup is used to transmit a digital signature indicating the
permission for the operation has been checked by the sending kernel.
The digital signature procedures have not yet been defined. This field
should be set to 0 for now to indicate no signature after the CREntity
parameter is set to the entity on which the operation is to be
performed.
Cheriton [page 101]
RFC1045 VMTP February 1988
IV. VMTP Entity Identifier Domains
VMTP allows for several disjoint naming domains for its endpoints. The
64-bit entity identifier is only unique and meaningful within its
domain. Each domain can define its own algorithm or mechanism for
assignment of entity identifiers, although each domain mechanism must
ensure uniqueness, stability of identifiers and host independence.
IV.1. Domain 1
For initial use of VMTP, we define the domain with Domain identifier 1
as follows:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
The Internet address is the Internet address of the host on which this
entity-id is originally allocated. The Discriminator is an arbitrary
value that is unique relative to this Internet host address. In
addition, the host must guarantee that this identifier does not get
reused for a long period of time after it becomes invalid. ("Invalid"
means that no VMTP module considers in bound to an entity.) One
technique is to use the lower order bits of a 1 second clock. The clock
need not represent real-time but must never be set back after a crash.
In a simple implementation, using the low order bits of a clock as the
time stamp, the generation of unique identifiers is overall limited to
no more than 1 per second on average. The type flags were described in
Section 3.1.
An entity may migrate between hosts. Thus, an implementation can
heuristically use the embedded Internet address to locate an entity but
should be prepared to maintain a cache of redirects for migrated
entities, plus accept Notify operations indicating that migration has
occurred.
Entity group identifiers in Domain 1 are structured in one of two forms,
depending on whether they are well-known or dynamically allocated
identifiers. A well-known entity identifier is structured as:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
Cheriton [page 102]
RFC1045 VMTP February 1988
with the second high-order bit (GRP) set to 1. This form of entity
identifier is mapped to the Internet host group address specified in the
low-order 32 bits. The Discriminator distinguishes group identifiers
using the same Internet host group. Well-known entity group identifiers
should be allocated to correspond to the basic services provided by
hosts that are members of the group, not specifically because that
service is provided by VMTP. For example, the well-known entity group
identifier for the domain name service should contain as its embedded
Internet host group address the host group for Domain Name servers.
A dynamically allocated entity identifier is structured as:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. The Internet address in
the low-order 32 bits is a Internet address assigned to the host that
dynamically allocates this entity group identifier. A dynamically
allocated entity group identifier is mapped to Internet host group
address 232.X.X.X where X.X.X are the low-order 24 bits of the
Discriminator subfield of the entity group identifier.
We use the following notation for Domain 1 entity identifiers <10> and
propose it use as a standard convention.
<flags>-<discriminator>-<Internet address>
where <flags> are [X]{BE,LE,RG,UG}[A]
X = reserved
BE = big-endian entity
LE = little-endian entity
RG = restricted group
UG = unrestricted group
A = alias
and <discriminator> is a decimal integer and <Internet address> is in
standard dotted decimal IP address notation.
Examples:
_______________
<10> This notation was developed by Steve Deering.
Cheriton [page 103]
RFC1045 VMTP February 1988
BE-25593-36.8.0.49 is big-endian entity #25593 created on host
36.8.0.49.
RG-1-224.0.1.0 is the well-known restricted VMTP managers group.
UG-565338-36.8.0.77 is unrestricted entity group #565338 created on host
36.8.0.77.
LEA-7823-36.8.0.77 is a little-endian alias entity #7823 created on host
36.8.0.77.
This notation makes it easy to communicate and understand entity
identifiers for Domain 1.
The well-known entity identifiers specified to date are:
VMTP_MANAGER_GROUP RG-1-224.0.1.0
Managers for VMTP operations.
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0
Client entity identifier to use when a (big-endian) host
has not determined or been allocated any client entity
identifiers.
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0
Client entity identifier to use when a (little-endian)
host has not determined or been allocated any client
entity identifiers.
Note that 224.0.1.0 is the host group address assigned to VMTP and to
which all VMTP hosts belong.
Other well-known entity group identifiers will be specified in
subsequent extensions to VMTP and in higher-level protocols that use
VMTP.
IV.2. Domain 3
Domain 3 is reserved for embedded systems that are restricted to a
single network and are independent of IP. Entity identifiers are
allocated using the decentralized approach described below. The mapping
of entity group identifiers is specific to the type of network being
used and not defined here. In general, there should be a simple
algorithmic mapping from entity group identifier to multicast address,
similar to that described for Domain 1. Similarly, the values for
default client identifier are specific to the type of network and not
Cheriton [page 104]
RFC1045 VMTP February 1988
defined here.
IV.3. Other Domains
Definition of additional VMTP domains is planned for the future.
Requests for allocation of VMTP Domains should be addressed to the
Internet protocol administrator.
IV.4. Decentralized Entity Identifier Allocation
The ProbeEntityBlock operation may be used to determine whether a block
of entity identifiers is in use. ("In use" means valid or reserved by a
host for allocation.) This mechanism is used to detect collisions in
allocation of blocks of entity identifiers as part of the implementation
of decentralized allocation of entity identifiers. (Decentralized
allocation is used in local domain use of VMTP such as in embedded
systems- see Domain 3.)
Basically, a group of hosts can form a Domain or sub-Domain, a group of
hosts managing their own entity identifier space or subspace,
respectively. As an example of a sub-Domain, a group of hosts in Domain
1 all identified with a particular host group address can manage the
sub-Domain corresponding to all entity identifiers that contain that
host group address. The ProbeEntityBlock operation is used to allocate
the random bits of these identifiers as follows.
When a host requires a new block of entity identifiers, it selects a new
block (randomly or by some choice algorithm) and then multicasts a
ProbeEntityBlock request to the members of the (sub-)Domain some R
times. If no response is received after R (re)transmissions, the host
concludes that it is free to use this block of identifiers. Otherwise,
it picks another block and tries again.
Notes:
1. A block of 256 identifiers is specified by an entity
identifier with the low-order 8 bits all zero.
2. When a host allocates an initial block of entity identifiers
(and therefore does not yet have a specified entity
identifier to use) it uses VMTP_DEFAULT_BECLIENT (if
big-endian, else VMTP_DEFAULT_LECLIENT if little-endian) as
its client identifier in the ProbeEntityBlock Request and a
transaction identifier of 0. As soon as it has allocated a
block of entity identifiers, it should use these identifiers
Cheriton [page 105]
RFC1045 VMTP February 1988
for all subsequent communication. The default client
identifier values are defined for each Domain.
3. The set of hosts using this decentralized allocation must not
be subject to network partitioning. That is, the R
transmissions must be sufficient to ensure that every host
sees the ProbeEntityBlock request and (reliably) sends a
response. (A host that detects a collision can retransmit
the response multiple times until it sees a new
ProbeEntityBlock operation from the same host/Client up to a
maximum number of times.) For instance, a set of machines
connected by a single local network may able to use this type
of allocation.
4. To guarantee T-stability, a host must prevent reuse of a
block of identifiers if any of the identifiers in the block
are currently valid or have been valid less than T seconds
previously. To this end, a host must remember recently used
identifiers and object to their reuse in response to a
ProbeEntityBlock operation.
5. Care is required in a VMTP implementation to ensure that
Probe operations cannot be discarded due to lack of buffer
space or queued or delayed so that a response is not
generated quickly. This is required not only to detect
collisions but also to provide accurate roundtrip estimates
as part of ProbeEntity operations.
Cheriton [page 106]
RFC1045 VMTP February 1988
V. Authentication Domains
A VMTP authentication domain defines the format and interpretation for
principal identifiers and encryption keys. In particular, an
authentication domain must specify a means by which principal
identifiers are allocated and guaranteed unique and stable. The
currently defined authentication domains are as follows (0 is reserved).
Ideally, all entities within one entity domain are also associated with
one authentication domain. However, authentication domains are
orthogonal to entity domains. Entities within one domain may have
different authentication domains. (In this case, it is generally
necessary to have some correspondence between principals in the
different domains.) Also, one entity identifier may be associated with
multiple authentication domains. Finally, one authentication domain may
be used across multiple entity domains.
V.1. Authentication Domain 1
A principal identifier is structured as follows.
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bits
The Internet Address may specify an individual host (such as a UNIX
machine) or may specify a host group address corresponding to a cluster
of machines operating under a single adminstration. In both cases,
there is assumed to be an adminstration associated with the embedded
Internet address that guarantees the uniqueness and stability of the
User Identifier relative to the Internet address. In particular, that
administration is the only one authorized to allocate principal
identifiers with that Internet address prefix, and it may allocate any
of these identifiers.
In authentication domain 1, the standard EncryptionQualifiers are:
0 Clear text - no encryption.
1 use 64-bit CBC DES for encryption and decryption.
V.2. Other Authentication Domains
Other authentication domains will be defined in the future as needed.
Cheriton [page 107]
RFC1045 VMTP February 1988
VI. IP Implementation
VMTP is designed to be implemented on the DoD IP Internet Datagram
Protocol (although it may also be implemented as a local network
protocol directly in "raw" network packets.)
VMTP is assigned the protocol number 81.
With a 20 octet IP header and one segment block, a VMTP packet is 600
octets. By convention, any host implementing VMTP implicitly agrees to
accept VMTP/IP packets of at least 600 octets.
VMTP multicast facilities are designed to work with, and have been
implemented using, the multicast extensions to the Internet [8]
described in RFC966 and 988. The wide-scale use of full VMTP/IP
depends on the availability of IP multicast in this form.
Cheriton [page 108]
RFC1045 VMTP February 1988
VII. Implementation Notes
The performance and reliability of a protocol in operation is highly
dependent on the quality of its implementation, in addition to the
"intrinsic" quality of the protocol design. One of the design goals of
the VMTP effort was to produce an efficiently implementable protocol.
The following notes and suggestions are based on experience with
implementing VMTP in the V distributed system and the UNIX 4.3 BSD
kernel. The following is described for a client and server handling
only one domain. A multi-domain client or server would replicate these
structures for each domain, although buffer space may be shared.
VII.1. Mapping Data Structures
The ClientMap procedure is implemented using a hash table that maps to
the Client State Record whether this entity is local or remote, as shown
in Figure VII-1.
+---+---+--------------------------+
ClientMap | | x | |
+---+-|-+--------------------------+
| +--------------+ +--------------+
+-->| LocalClient |--->| LocalClient |
+--------------+ +--------------+
| RemoteClient | | RemoteClient |-> ...
+--------------+ +--------------+
| | | |
| | | |
+--------------+ +--------------+
Figure VII-1: Mapping Client Identifier to CSR
Local clients are linked through the LocalClientLink, similarly for the
RemoteClientLink. Once a CSR with the specified Entity Id is found,
some field or flag indicates whether it is identifying a local or remote
Entity. Hash collisions are handled with the overflow pointers
LocalClientLink and RemoteClientLink (not shown) in the CSR for the
LocalClient and RemoteClient fields, respectively. Note that a CSR
representing an RPC request has both a local and remote entity
identifier mapping to the same CSR.
The Server specified in a Request is mapped to a server descriptor using
the ServerMap (with collisions handled by the overflow pointer.). The
server descriptor is the root of a queue of CSR's for handling requests
plus flags that modify the handling of the Request. Flags include:
Cheriton [page 109]
RFC1045 VMTP February 1988
+-------+---+-------------------------+
ServerMap | | x | |
+-------+-|-+-------------------------+
| +--------------+
| | OverflowLink |
| +--------------+
+-->| Server |
+--------------+
| Flags | Lock |
+--------------+
| Head Pointer |
+--------------+
| Tail Pointer |
+--------------+
Figure VII-2: Mapping Server Identifiers
THREAD_QUEUE Request is to be invoked directly as a remote procedure
invocation, rather than by a server process in the
message model.
AUTHENTICATION_REQUIRED
Sent a Probe request to determine principal associated
with the Client, if not known.
SECURITY_REQUIRED
Request must be encrypted or else reject.
REQUESTS_QUEUED Queue contains waiting requests, rather than free CSR's.
Queue this request as well.
SERVER_WAITING The server is waiting and available to handle incoming
Request immediately, as required by CMD.
Alternatively, the Server identifiers can be mapped to a CSR using the
MapToClient mechanism with a pointer in the CSR refering to the server
descriptor, if any. This scheme is attractive if there are client CSR's
associated with a service to allow it to communicate as a client using
VMTP with other services.
Finally, a similar structure is used to expand entity group identifiers
to the local membership, as shown in Figure VII-3. A group identifier
is hashed to an index in the GroupMap. The list of group descriptors
rooted at that index in the GroupMap contains a group descriptor for
each local member of the group. The flags are the group permissions
defined in Appendix III.
Cheriton [page 110]
RFC1045 VMTP February 1988
+-------+---+----------------------------------+
GroupMap | | x | |
+-------+-|-+----------------------------------+
| +--------------+
| | OverflowLink |
| +--------------+
+-->|EntityGroupId |
+--------------+
| Flags |
+--------------+
| Member Entity|
+--------------+
Figure VII-3: Mapping Group Identifiers
Note that the same pool of descriptors could be used for the server and
group descriptors given that they are similar in size.
VII.2. Client Data Structures
Each client entity is represented as a client state record. The CSR
contains a VMTP header as well as other bookkeeping fields, including
timeout count, retransmission count, as described in Section 4.1. In
addition, there is a timeout queue, transmission queue and reception
queue. Finally, there is a ServerHost cache that maps from server
entity-id records to host address, estimated round trip time,
interpacket gap, MTU size and (optimally) estimated processing time for
this server entity.
VII.3. Server Data Structures
The server maintains a heap of client state records (CSR), one for each
(Client, Transaction). (If streams are not supported, there is, at
worst, a CSR per Client with which the server has communicated with
recently.) The CSR contains a VMTP header as well as various
bookkeeping fields including timeout count, retransmission count. The
server maintains a hash table mapping of Client to CSR as well as the
transmission, timeout and reception queues. In a VMTP module
implementing both the client and server functions, the same timeout
queue and transmission queue are used for both.
Cheriton [page 111]
RFC1045 VMTP February 1988
VII.4. Packet Group transmission
The procedure SendPacketGroup( csr ) transmits the packet group
specified by the record CSR. It performs:
1. Fragmentation of the segment data, if any, into packets.
(Note, segment data flagged by SDA bit.)
2. Modifies the VMTP header for each packet as required e.g.
changing the delivery mask as appropriate.
3. Computes the VMTP checksum.
4. Encrypts the appropriate portion of the packet, if required.
5. Prepends and appends network-level header and trailer using
network address from ServerHost cache, or from the responding
CSR.
6. Transmits the packet with the interpacket gap specified in
the cache. This may involve round-robin scheduling between
hosts as well as delaying transmissions slightly.
7. Invokes the finish-up procedure specified by the CSR record,
completing the processing. Generally, this finish-up
procedure adds the record to the timeout queue with the
appropriate timeout queue.
The CSR includes a 32-bit transmission mask that indicates the portions
of the segment to transmit. The SendPacketGroup procedure is assumed to
handle queuing at the network transmission queue, queuing in priority
order according to the priority field specified in the CSR record.
(This priority may be reflected in network transmission behavior for
networks that support priority.)
The SendPacketGroup procedure only looks at the following fields of a
CSR
- Transmission mask
- FuncCode
- SDA
- Client
- Server
Cheriton [page 112]
RFC1045 VMTP February 1988
- CoResidentEntity
- Key
It modifies the following fields
- Length
- Delivery
- Checksum
In the case of encrypted transmission, it encrypts the entire packet,
not including the Client field and the following 32-bits.
If the packet group is a Response, (i.e. lower-order bit of function
code is 1) the destination network address is determined from the
Client, otherwise the Server. The HostAddr field is set either from the
ServerHost cache (if a Request) or from the original Request if a
Response, before SendPacketGroup is called.
The CSR includes a timeout and TTL fields indicating the maximum time to
complete the processing and the time-to-live for the packets to be
transmitted.
SendPacketGroup is viewed as the right functionality to implement for
transmission in an "intelligent" network interface.
Finally, it appears preferable to be able to assume that all portions of
the segment remain memory-resident (no page faults) during transmission.
In a demand-paged systems, some form of locking is required to keep the
segment data in memory.
VII.5. VMTP Management Module
The implementation should implement the management operations as a
separate module that is invoked from within the VMTP module. When a
Request is received, either from the local user level or the network,
for the VMTP management module, the management module is invoked as a
remote or local procedure call to handle this request and return a
response (if not a datagram request). By registering as a local server,
the management module should minimize the special-case code required for
its invocation. The management module is basically a case statement
that selects the operation based on the RequestCode and then invokes the
specified management operation. The procedure implementing the
management operation, especially operations like NotifyVmtpClient and
Cheriton [page 113]
RFC1045 VMTP February 1988
NotifyVmtpServer, are logically part of the VMTP module because they
require full access to the basic data structures of the VMTP
implementation.
The management module should be implemented so that it can respond
quickly to all requests, particularly since the timing of management
interactions is used to estimate round trip time. To date, all
implementations of the management module have been done at the kernel
level, along with VMTP proper.
VII.6. Timeout Handling
The timeout queue is a queue of CSR records, ordered by timeout count,
as specified in the CSR record. On entry into the timeout queue, the
CSR record has the timeout field set to the time (preferable in
milliseconds or similar unit) to remain in the queue plus the finishup
field set to the procedure to execute on removal on timeout from the
queue. The timeout field for a CSR in the queue is the time relative to
the record preceding it in the queue (if any) at which it is to be
removed. Some system-specific mechanism decrements the time for the
record at the front of the queue, invoking the finishup procedure when
the count goes to zero.
Using this scheme, a special CSR is used to timeout and scan CSR's for
non-recently pinged CSR's. That is, this CSR times out and invokes a
finishup procedure that scans for non-recently pinged CSR that are
"AwaitingResponse" and signals the request processing entity and deletes
the CSR. It then returns to the timeout queue.
The timeout mechanism tends to be specific to an operating system. The
scheme described may have to be adapted to the operating system in which
VMTP is to be implemented.
This mechanism handles client request timeout and client response
timeout. It is not intended to handle interpacket gaps given that these
times are expected to be under 1 millisecond in general and possibly
only a few microseconds.
VII.7. Timeout Values
Roundtrip timeout values are estimated by matching Responses or
NotifyVmtpClient Requests to Request transmission, relying on the
retransmitCount to identify the particular transmission of the Request
that generated the response. A similar technique can be used with
Responses and NotifyVmtpServer Requests. The retransmitCount is
Cheriton [page 114]
RFC1045 VMTP February 1988
incremented each time the Response is sent, whether the retransmission
was caused by timeout or retransmission of the Request.
The ProbeEntity request is recommended as a basic way of getting
up-to-date information about a Client as well as predictable host
machine turnaround in processing a request. (VMTP assumes and requires
an efficient, bounded response time implementation of the ProbeEntity
operation.)
Using this mechanism for measuring RTT, it is recommended that the
various estimation and smoothing techniques developed for TCP RTT
estimation be adapted and used.
VII.8. Packet Reception
Logically a network packet containing a VMTP packet is 5 portions:
- network header, possibly including lower-level headers
- VMTP header
- data segment
- VMTP checksum
- network trailer, etc.
It may be advantageous to receive a packet fragmented into these
portions, if supported by the network module. In this case, ideally the
VMTP header may be received directly into a CSR, the data segment into a
page that can be mapped, rather than copied, to its final destination,
with VMTP checksum and network header in a separate area (used to
extract the network address corresponding to the sender).
Packet reception is described in detail by the pseudo-code in Section
4.7.
With a response, normally the CSR has an associated segment area
immediately available so delivery of segment data is immediate.
Similarly, server entities should be "armed" with CSR's with segment
areas that provide for immediate delivery of requests. It is reasonable
to discard segment data that cannot be immediately delivered in this
way, providing that clients and servers are able to preallocate CSR's
with segment areas for requests and responses. In particular, a client
should be able to provide some number of additional CSR's for receiving
multiple responses to a multicast request.
Cheriton [page 115]
RFC1045 VMTP February 1988
The CSR data structure is intended to be the interface data structure
for an intelligent network interface. For reception, the interface is
"armed" with CSR's that may point to segment areas in main memory, into
which it can deliver a packet group. Ideally, the interface handles all
the processing of all packets, interacting with the host after receiving
a complete Request or Response packet group. An implementation should
use an interface based on SendPacketGroup(CSR) and
ReceivePacketGroup(CSR) to facilitate the introduction of an intelligent
network interface.
ReceivePacketGroup(csr) provides the interface with a CSR descriptor and
zero or more bytes of main memory to receive segment data. The CSR
describes whether it is to receive responses (and if so, for which
client) or requests (and if so for which server).
The procedure ReclaimCSR(CSR) reclaims the specified record from the
interface before it has been returned after receiving the specified
packet group.
A finishup procedure is set in the CSR to be invoked when the CSR is
returned to the host by the normal processing sequence in the interface.
Similarly, the timeout parameter is set to indicate the maximum time the
host is providing for the routine to perform the specified function.
The CSR and associated segment memory is returned to the host after the
timeout period with an indication of progress after the timeout period.
It is not returned earlier.
VII.9. Streaming
The implementation of streaming is optional in both VMTP clients and
servers. Ideally, all performance-critical servers should implement
streaming. In addition, clients that have high context switch overhead,
network access overhead or expect to be communicating over long delay
links should also implement streaming.
A client stream is implemented by allocating a CSR for each outstanding
message transaction. A stream of transactions is handled similarly to
multiple outstanding transactions from separate clients except for the
interaction between consecutive numbered transactions in a stream.
For the server VMTP module, streamed message transactions to a server
are queued (if accepted) subordinate to the first unprocessed CSR
corresponding to this Client. Thus, streamed transactions from a given
Client are always performed in the order specified by the transaction
identifiers.
Cheriton [page 116]
RFC1045 VMTP February 1988
If a server does not implement streaming, it must refuse streamed
message transactions using the NotifyVmtpClient operation. Also, all
client VMTP's that support streaming must support the streamed interface
to a server that does not support streaming. That is, it must perform
the message transactions one at a time. Consequently, a program that
uses the streaming interface to a non-streaming server experiences
degraded performance, but not failure.
VII.10. Implementation Experience
The implementation experience to date includes a partial implementation
(minus the streaming and full security) in the V kernel plus a similar
preliminary implementation in the 4.3 BSD Unix kernel. In the V kernel
implementation, the CSR's are part of the (lightweight) process
descriptor.
The V kernel implementation is able to perform a VMTP message
transaction with no data segment between two Sun-3/75's connected by 10
Mb Ethernet in 2.25 milliseconds. It is also able to transfer data at
4.7 megabits per second using 16 kilobyte Requests (but null checksums.)
The UNIX kernel implementation running on Microvax II's achieves a basic
message transaction time of 9 milliseconds and data rate of 1.9 megabits
per second using 16 kilobyte Responses. This implementation is using
the standard VMTP checksum.
We hope to report more extensive implementation experience in future
revisions of this document.
Cheriton [page 117]
RFC1045 VMTP February 1988
VIII. UNIX 4.3 BSD Kernel Interface for VMTP
UNIX 4.3 BSD includes a socket-based design for program interfaces to a
variety of protocol families and types of protocols (streams,
datagrams). In this appendix, we sketch an extension to this design to
support a transaction-style protocol. (Some familiarity with UNIX 4.2/3
IPC is assumed.) Several extensions are required to the system
interface, rather than just adding a protocol, because no provision was
made for supporting transaction protocols in the original design. These
extensions include a new "transaction" type of socket plus new system
calls invoke, getreply, probeentity, recreq, sendreply and forward.
A socket of type transaction bound to the VMTP protocol type
IPPROTO_VMTP is created by the call
s = socket(AF_INET, SOCK_TRANSACT, VMTP);
This socket is bound to an entity identifier by
bind(s, &entityid, sizeof(entityid));
The first address/port bound to a socket is considered its primary name
and is the one used on packet transmission. A message transaction is
invoked between the socket named by s and the Server specified by mcb by
invoke(s, mcb, segptr, seglen, timeout );
The mcb is a message control block whose format was described in Section
2.4. The message control block specifies the request to send plus the
destination Server. The response message control block returned by the
server is stored in mcb when invoke returns. The invoking process is
blocked until a response is received or the message transaction times
out unless the request is a datagram request. (Non-blocking versions
with signals on completion could also be provided, especially with a
streaming implementation.)
For multicast message transactions (sent to an entity group), the next
response to the current message transaction (if it arrives in less than
timeout milliseconds) is returned by
getreply( s, mcb, segptr, maxseglen, timeout );
The invoke operation sent to an entity group completes as soon as the
first response is received. A request is retransmitted until the first
reply is received (assuming the request is not a datagram). Thus, the
system does not retransmit while getreply is timing out even if no
replies are available.
Cheriton [page 118]
RFC1045 VMTP February 1988
The state of an entity associated with entityId is probed using
probeentity( entityId, state );
A UNIX process acting as a VMTP server accepts a Request by the
operation
recvreq(s, mcb, segptr, maxseglen );
The request message for the next queued transaction request is returned
in mcb, plus the segment data of maximum length maxseglen, starting at
segptr in the address space. On return, the message control block
contains the values as set in invoke except: (1) the Client field
indicates the Client that sent the received Request message. (2) the
Code field indicates the type of request. (3) the MsgDelivery field
indicates the portions of the segment actually received within the
specified segment size, if MDM is 1 in the Code field. A segment block
is marked as missing (i.e. the corresponding bit in the MsgDelivery
field is 0) unless it is received in its entirety or it is all of the
data in last segment contained in the segment.
To complete a transaction, the reply specified by mcb is sent to the
client specified by the MCB using
sendreply(s, mcb, segptr );
The Client field of the MCB indicates the client to respond to.
Finally, a message transaction specified by mcb is forwarded to
newserver as though it were sent there by its original invoker using
forward(s, mcb, segptr, timeout );
Cheriton [page 119]
RFC1045 VMTP February 1988
Index
Acknowledgment 14
APG 16, 31, 39
Authentication domain 20
Big-endian 9
Checksum 14, 43
Checksum, not set 44
Client 7, 10, 38
Client timer 16
CMD 42, 110
CMG 32, 40
Co-resident entity 25
Code 42
CoResidentEntity 42, 43
CRE 21, 42
DGM 42
Digital signature, VMTP management 95, 101
Diskless workstations 2
Domain 9, 38
Domain 1 102
Domain 3 104
Entity 7
Entity domain 9
Entity group 8
Entity identifier 37
Entity identifier allocation 105
Entity identifier, all-zero 38
EPG 20, 39
Features 6
ForwardCount 24
Forwarding 24
FunctionCode 41
Group 8
Group message transaction 10
Group timeouts 16
GRP 37
HandleNoCSR 62
HandleRequestNoCSR 79
HCO 14, 23, 39
Cheriton [page 120]
RFC1045 VMTP February 1988
Host independence 8
Idempotent 15
Interpacket gap 18, 40
IP 108
Key 91
LEE 32, 37
Little-endian 9
MCB 118
MDG 22, 40
MDM 30, 42
Message control block 118
Message size 6
Message transaction 7, 10
MPG 39
MsgDelivery 43
MSGTRANS_OVERFLOW 27
Multicast 4, 21, 120
Multicast, reliable 21
Naming 6
Negative acknowledgment 31
NER 25, 31, 39
NRT 26, 30, 39
NSR 25, 27, 31, 39
Object-oriented 2
Overrun 18
Packet group 7, 29, 39
Packet group run 31
PacketDelivery 29, 31, 41
PGcount 26, 41
PIC 42
Principal 11
Priority 41
Process 11
ProcessId 89
Protocol number,IP 108
RAE 37
Rate control 18
Real-time 2, 4
Realtime 22
Cheriton [page 121]
RFC1045 VMTP February 1988
Reliability 12
Request message 10
RequestAckRetries 30
RequestRetries 15
Response message 10
ResponseAckRetries 31
ResponseRetries 15
Restricted group 8
Retransmission 15
RetransmitCount 17
Roundtrip time 17
RPC 2
Run 31, 39
Run, message transactions 25
SDA 42
Security 4, 19
Segment block 41
Segment data 43
SegmentSize 42, 43
Selective retransmission 18
Server 7, 10, 41
Server group 8
Sockets, VMTP 118
STI 26, 40
Streaming 25, 55
Strictly stable 8
Subgroups 21
T-stable 8
TC1(Server) 16
TC2(Server) 16
TC3(Server) 16
TC4 16
TCP 2
Timeouts 15
Transaction 10, 41
Transaction identification 10
TS1(Client) 17
TS2(Client) 17
TS3(Client) 17
TS4(Client) 17
TS5(Client) 17
Type flags 8
UNIX interface 118
Unrestricted group 8, 38
Cheriton [page 122]
RFC1045 VMTP February 1988
NotifyVmtpClient 7, 26, 27, 30
NotifyVmtpServer 7, 14, 30
User Data 43
Version 38
VMTP Management digital signature 95, 101
Cheriton [page 123]