1 - 2 - 3 - 4 - 6 - 8 - A - B - C - D - E - F - G - H - I - J - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
transaction
Click on the red underlined text to get to the source
...
The Versatile Message Transaction Protocol (VMTP) is a transport
protocol designed to support remote procedure call ...
... designed to support remote procedure call (RPC) and general
transaction-oriented communication. By transaction-oriented
communication, we mean that:
...
... (RPC) and general
transaction-oriented communication. By transaction-oriented
communication, we mean that:
...
... client may ask for the next
page of a file as the service. The transaction is terminated
by the server responding with the next page.
...
... by the server responding with the next page.
- A transaction is initiated as part of sending a request to a
server and terminated by the server responding. There are no
...
... or failures.
The term message transaction (or transaction) is used in the reminder of
this document for a request-response ...
...
The term message transaction (or transaction) is used in the reminder of
this document for a request-response exchange in the sense described
...
...
The protocol is designed to provide a range of behaviors within the
transaction model, including:
- Minimal two packet exchanges for short, simple transactions ...
... transaction model, including:
- Minimal two packet exchanges for short, simple transactions.
- Streaming of multi-packet requests and responses for efficient
...
... Datagram and multicast communication as an extension of the
transaction model.
Example Uses:
...
... update a replicated object,
synchronize the commitment of a distributed transaction, etc.
- Distributed real-time ...
...
VMTP provides an efficient, reliable, optionally secure transport
service in the message transaction or request-response model with the
following features:
...
... 2.5.6.)
- Secure message transactions with provision for a variety of
encryption schemes. (Section 2.6.)
...
...
- Multicast message transactions with multiple response messages
per request message. (Section 2.7.)
...
... - Support for real-time communication with idempotent message
transactions with minimal server overhead and state (Section
...
... 2.5.3), datagram request message transactions with no
response, optional header-only checksum ...
... checksum, priority processing
of transactions, conditional delivery and preemptive handling
of requests (Section 2.8)
...
...
- Forwarded message transactions as an optimization for certain
forms of nested remote procedure calls or message
...
... forms of nested remote procedure calls or message
transactions. (Section 2.9.)
- Multiple outstanding (asynchronous ...
... transport communication between network-
visible entities via message transactions. A message transaction
consists of a request message ...
... network-
visible entities via message transactions. A message transaction
consists of a request message sent by the client ...
... Message Transactions ...
...
The message transaction is the unit of interaction between a Client that
initiates the transaction ...
... transaction is the unit of interaction between a Client that
initiates the transaction and one or more Servers. A message
transaction starts with a ...
... that
initiates the transaction and one or more Servers. A message
transaction starts with a request message generated by a client ...
... client. At
the service interface, a server becomes involved with a transaction by
receiving and accepting the request. A server terminates its
involvement with a ...
... by
receiving and accepting the request. A server terminates its
involvement with a transaction by sending a response message. In a
group message ...
... by sending a response message. In a
group message transaction, the server entity designated by the client
...
... group receives a copy of the request. In the client's view, the
transaction is terminated when it receives the response message or, in
the case of a group ...
... response message or, in
the case of a group message transaction, when it receives the last
response message. Because it is normally impractical to determine when
the last ...
... response message. Because it is normally impractical to determine when
the last response message has been received. the current transaction is
terminated by VMTP when the next transaction ...
... Within an entity domain, a transaction is uniquely identified by the
tuple (Client, Transaction ...
... transaction is uniquely identified by the
tuple (Client, Transaction, ForwardCount). where Transaction is a
32-bit number and ForwardCount is a ...
... tuple (Client, Transaction, ForwardCount). where Transaction is a
32-bit number and ForwardCount is a 4-bit value. A ...
... 4-bit value. A Client uses
monotonically increasing Transaction identifiers for new message
transactions. Normally, the next higher ...
... monotonically increasing Transaction identifiers for new message
transactions. Normally, the next higher transaction number, modulo
2**32, is used for the next message transaction ...
... identifiers for new message
transactions. Normally, the next higher transaction number, modulo
2**32, is used for the next message transaction, although there are
...
... transactions. Normally, the next higher transaction number, modulo
2**32, is used for the next message transaction, although there are
cases in which it skips a small range of Transaction ...
... transaction, although there are
cases in which it skips a small range of Transaction identifiers. (See
the description of the STI control flag.) The ForwardCount is used when
...
... identifiers. (See
the description of the STI control flag.) The ForwardCount is used when
a message transaction is forwarded and is zero otherwise.
A Client ...
... A Client generates a stream of message transactions with increasing
transaction identifiers, directed at a diversity of Servers. We say a
...
... generates a stream of message transactions with increasing
transaction identifiers, directed at a diversity of Servers. We say a
...
... , directed at a diversity of Servers. We say a
Client has a transaction outstanding if it has invoked a message
transaction, but has not received the last Response (or possibly any
Response). Normally, a ...
... Client has a transaction outstanding if it has invoked a message
transaction, but has not received the last Response (or possibly any
Response). Normally, a Client has only one transaction ...
... transaction, but has not received the last Response (or possibly any
Response). Normally, a Client has only one transaction outstanding at a
time. However, VMTP allows a Client ...
... time. However, VMTP allows a Client to have multiple message
transactions outstanding simultaneously, supporting streamed,
asynchronous remote procedure call invocations. In addition, ...
...
A message transaction consists of a request message and one or more
Response messages. A message is structured as message control block
...
... Transaction Identifiers ...
...
Each message transaction is uniquely identified by the pair (Client,
Transaction). (We defer ...
... Each message transaction is uniquely identified by the pair (Client,
Transaction). (We defer discussion of the ForwardCount field to Section
2.9.) The 32-bit ...
... discussion of the ForwardCount field to Section
2.9.) The 32-bit transaction identifier is initialized to a random
value when the Client ...
... or allocated its entity
identifier. The transaction identifier is incremented at the end of
each message transaction ...
... transaction identifier is incremented at the end of
each message transaction. All Responses with the same specified
(Client, Transaction ...
... transaction. All Responses with the same specified
(Client, Transaction) pair are associated with this Request.
The transaction ...
... Transaction) pair are associated with this Request.
The transaction identifier is used for duplicate suppression at the
Server. A Server maintains a state ...
... Client for which it
is processing a Request, identified by (Client, Transaction). A Request
with the same (Client, Transaction ...
... Transaction). A Request
with the same (Client, Transaction) pair is discarded as a duplicate.
(The ForwardCount field must also be equal.) Normally, this record is
retained for some period after the Response is sent, allowing the Server
...
... Client to determine the Client's current
Transaction identifier (and other information), initialize a
new state ...
... A Request is normally acknowledged by receipt of a Response associated
with the Request, i.e. with the same (Client, Transaction). With
streamed message transactions, it may also be acknowledged by a
...
... Client, Transaction). With
streamed message transactions, it may also be acknowledged by a
subsequent Response that acknowledges previous Requests in addition to
the transaction ...
... transactions, it may also be acknowledged by a
subsequent Response that acknowledges previous Requests in addition to
the transaction it explicitly identifies. A Response may be explicitly
acknowledged by a NotifyVmtpServer operation requested of the manager
for the Server. In the case of streaming, this is a cumulative
acknowledgment ...
... acknowledged by a NotifyVmtpServer operation requested of the manager
for the Server. In the case of streaming, this is a cumulative
acknowledgment, acknowledging all Responses with a lower transaction
identifier as well.) In addition, with non-streamed communication, a
subsequent Request from the same ...
... subsequent Request from the same Client acknowledges Responses to all
previous message transactions (at least in the sense that either the
client received a Response or is no longer interested in Responses to
...
... client received a Response or is no longer interested in Responses to
those earlier message transactions). Finally, a client response timeout
(at the server) acknowledges a Response at least in the sense that the
...
... passing the Request on to the server again to have it regenerate the
Response (by redoing the operation), rather than saving a copy of the
Response. Only Request packets for the last transaction from this
client are passed on in this fashion; older Request packets from this
client ...
... timer for each Client with an outstanding
transaction. Similarly, there is one server timer for each Client
...
... . Similarly, there is one server timer for each Client
transaction that is "active" at the server, i.e. there is a transaction
...
...
transaction that is "active" at the server, i.e. there is a transaction
record for a Request from the Client.
...
...
segment need to be retransmitted. With streaming, the timeout applies
to the oldest outstanding message transaction in the run of outstanding
message transactions. Without streaming, there is one message
...
... to the oldest outstanding message transaction in the run of outstanding
message transactions. Without streaming, there is one message
transaction in the run, reducing to the previous situation. After the
first packet of a Response is received, the ...
... in the run of outstanding
message transactions. Without streaming, there is one message
transaction in the run, reducing to the previous situation. After the
first packet of a Response is received, the Client resets the timeout to
...
... retransmission
for long running transactions is insignificant. A sophisticated
implementation may make the estimation of TC1 further specific to the
Server.
...
... state can be. In particular, TS2 should be
significantly less than the minimum time within which it
is reasonable to reuse a transaction identifier.
...
... Probe on the Client to get the needed information.) It
should also be set low enough so that the transaction identifier cannot
wrap around and so that the Server does not run out of CSR's. We
...
... non-secure VMTP
message transaction. If a server receives a secure Request for which
the server has no entity state ...
... with a working Key that is shared between Client and Server.
Impostoring and replays are detected by comparing the Transaction
identifier with that stored in the corresponding entity ...
... Security is optional in the sense that messages may be secure or
non-secure, even between consecutive message transactions from the same
client. It is also optional in that VMTP ...
... The Server entity identifier in a message transaction can identify an
entity group, in which case the Request is ...
... streaming) of each new Request from a Client terminating the previous
message transactions from that Client, if any, provides the "most recent
is most important" handling of processing that most real-time
applications ...
... Forwarded Message Transactions ...
... Client.
If the message transaction being forwarded was not multicast, not secure
or the two Servers are the same principal ...
... sending a Request onto the next
Server with the forwarded Request identified by the same Client and
Transaction as the original Request and a ForwardCount one greater than
the Request received from the Client. In this case, the new Server ...
... +----------+
If the message transaction does not meet the above requirements, the
Server's VMTP ...
... the return to the invoking call directly. The Server may also use this
form of forwarding when the Request is part of a stream of message
transactions. Otherwise, it must wait until the forwarded message
transaction completes before proceeding with the subsequent message
...
... transactions. Otherwise, it must wait until the forwarded message
transaction completes before proceeding with the subsequent message
transactions in the stream.
...
... forwarded message
transaction completes before proceeding with the subsequent message
transactions in the stream.
...
... normal incoming Request. In particular, it is only necessary to examine
the ForwardCount field when the Transaction of the Request matches that
of the last message transaction received from the Client ...
... the ForwardCount field when the Transaction of the Request matches that
of the last message transaction received from the Client. Thus, the
additional complexity in the VMTP ...
... VMTP management server module that is invoked
using a message transaction addressed to the Server, VMTP_MANAGER_GROUP,
...
... Streamed Message Transactions ...
...
Streamed message transactions refer to two or more message transactions
initiated by a Client ...
...
Streamed message transactions refer to two or more message transactions
initiated by a Client before it receives the response to the first
...
... initiated by a Client before it receives the response to the first
message transaction, with each transaction being processed and responded
to in order but asynchronous ...
... Client before it receives the response to the first
message transaction, with each transaction being processed and responded
to in order but asynchronous relative to the initiation of the
...
... being processed and responded
to in order but asynchronous relative to the initiation of the
transactions. A Client streams messages transactions, and thereby has
...
... relative to the initiation of the
transactions. A Client streams messages transactions, and thereby has
multiple message transactions outstanding, by sending them as part of a
...
... Client streams messages transactions, and thereby has
multiple message transactions outstanding, by sending them as part of a
single run of message transactions. A run of message transactions ...
... multiple message transactions outstanding, by sending them as part of a
single run of message transactions. A run of message transactions is a
sequence of message ...
... transactions outstanding, by sending them as part of a
single run of message transactions. A run of message transactions is a
sequence of message transactions with the same ...
... . A run of message transactions is a
sequence of message transactions with the same Client and Server and
consecutive Transaction ...
... transactions with the same Client and Server and
consecutive Transaction identifiers, with all but the first and last
Requests and Responses flagged with the NSR (Not Start ...
... Request and Response
does not have the NER bit set.) The message transactions in a run use
consecutive transaction identifiers ...
... bit set.) The message transactions in a run use
consecutive transaction identifiers (except if the STI bit <4> is used
...
... identifiers (except if the STI bit <4> is used
in one, in which case the transaction identifier for the next message
transaction is 256 greater, rather than 1).
...
... in one, in which case the transaction identifier for the next message
transaction is 256 greater, rather than 1).
The Client ...
... The Client retains a record for each outstanding transaction until it
gets a Response or is timed out in error. The record provides the
information required to retransmit the Request. On retransmission
timeout ...
... retransmits the last Request for which it has not
received a Response the same as is done with non-streamed communication.
(I.e. there need be only one timeout for all the outstanding message
transactions associated with a single client.)
...
... client.)
The consecutive transaction identifiers within a run of message
transactions are used as ...
... The consecutive transaction identifiers within a run of message
transactions are used as sequence numbers for error control. The Server
handles each message transaction ...
... transactions are used as sequence numbers for error control. The Server
handles each message transaction in the sequence specified by its
transaction identifier. When it receives a message ...
... for error control. The Server
handles each message transaction in the sequence specified by its
transaction identifier. When it receives a message transaction that is
...
... in the sequence specified by its
transaction identifier. When it receives a message transaction that is
not marked as the beginning of a run, it checks that it previously
received a message transaction ...
... transaction that is
not marked as the beginning of a run, it checks that it previously
received a message transaction with the predecessor transaction
identifier, either 1 less than the current one or 256 less if the
...
... not marked as the beginning of a run, it checks that it previously
received a message transaction with the predecessor transaction
identifier, either 1 less than the current one or 256 less if the
previous one had the STI ...
... NotifyVmtpClient operation to the Client's manager indicating either:
(1) the first message transaction was not fully received, or else (2) it
has no record of the last one received. If the NRT control flag is set,
it does not await nor expect retransmission ...
... datagram Requests are
used as part of a stream of message transactions. If NRT was not
specified, the Client must retransmit from the first message transaction ...
... transactions. If NRT was not
specified, the Client must retransmit from the first message transaction
not fully received (either at all or in part) before the Server can
proceed with handling this run of Requests or else restart ...
... proceed with handling this run of Requests or else restart the run of
message transactions.
The Client ...
... The Client expects to receive the Responses in a consecutive sequence,
using the Transaction identifier to detect missing Responses. Thus, the
Server must return Responses in sequence except possibly for some gaps,
...
... <4> The STI bit is used by the Client to effectively allocate 255
transaction identifiers for use by the Server in returning a large
...
...
corresponds to, up to a maximum of 255 previous Responses <5>. Thus,
for example, a Response with Transaction identifier 46 and PGcount 3
represents Responses 43, 44, 45 and 46. This facility allows the Server
...
... to effectively maintain strictly consecutive sequencing when the Client
has skipped 256 Transaction identifiers using the STI bit and the Server
...
... datagrams).
The Client should wait at the end of a run of message transactions for
the last one to complete.
...
...
When a Server receives a Request with the NSR bit clear and a higher
transaction identifier than it currently has for the Client, it
...
... terminates all processing and discards Responses associated with the
previous Requests. Thus, a stream of message transactions is
effectively aborted by starting a new run, even if the Server was in the
...
... datagram and normal Requests as part of a stream of
message transactions, particularly with the use of the NRT bit, can lead
to complex behavior under packet loss ...
... to complex behavior under packet loss. It is recommended that a run of
message transactions be all of one type to avoid problems, i.e. all
normal or all datagrams. Finally, when a Server forwards a Request that
...
... Requests until the forwarded Request has been handled, to preserve order
of processing. The simplest handling of this situation is to use a real
nested call when forwarding with streamed message transactions.
Flow control of streamed message ...
... .
Flow control of streamed message transactions relies on rate control at
the Client plus receipt (or non-receipt) of management ...
... indicating the presence of overrunning. A Client must reduce the number
of outstanding message transactions at the Server when it receives a
NotifyVmtpServer operation with the MSGTRANS_OVERFLOW ResponseCode. The
transact parameter indicates the last packet group ...
... group.
The implementation of multiple outstanding message transactions requires
the ability to record, timeout and buffer multiple outstanding message
...
... requires
the ability to record, timeout and buffer multiple outstanding message
transactions at the Client end as well as the Server end. However, this
facility is optional for both the Client ...
... sender can detect if it failed to receive the
notify operation in the previous case. With Responses, the packets are
ordered by the Transaction identifier except for multicast message
...
... identifier except for multicast message
transactions, in which there may be multiple Responses with the same
identification. In this case, NotifyVmtpServer operations are used to
provide receive sequence numbers ...
... groups. A packet group is one or more packets, each containing the same
transaction identification and message control block. Each packet is
formatted as below with the message control block logically embedded in
the VMTP ...
... group
contains the same Client, Server, Transaction identifier and SegmentSize
fields. It is a protocol error ...
... , all Request
packets or all Response packets, with the same Client and consecutive
transaction identifiers, all but the first and last packets flagged with
the NSR (Not Start ...
... packet group in the run corresponds to a single Request or Response, it
is identical to a run of message transactions. (See Section 2.11)
However, a Request message or a Response message ...
... Probe and Notify
operations to locate a Server and acknowledge responses. (the latter
only if it is involved in transactions that are not idempotent or
datagram message transactions. However, a simple sensor, for example,
...
... only if it is involved in transactions that are not idempotent or
datagram message transactions. However, a simple sensor, for example,
can transmit VMTP datagram ...
... A minimal VMTP server implements idempotent, non-encrypted message
transactions, possibly with no segment data support. It should use an
entity ...
... buffering (outside of immediate request
processing) or queuing. In particular, it needs only as many records as
message transactions it handles simultaneously (e.g. 1). The entity
state record is required to recognize and respond to Request
...
... message handling of a request appear no differently to the client
invoking the message transaction, except possibly for differences in
performance.
...
... update on the state of the
transaction as soon as the request packet group is
received, independent of the response being available.
...
... identifier that the Client plans to use is the current
transaction plus 256, if part of the same run and at
least this big if not. In a Request, this authorizes
the Server to send back up to 256 packet groups ...
... group prior to this one, modulo 8. This field is
used in estimation of roundtrip times. This count may
wrap around during a message transaction. However, it
should be sufficient to match acknowledgments and
responses with a particular transmission.
...
... group
represents in addition to that specified by the
Transaction field. This is used in acknowledging
multiple packet groups in streamed communication.
...
... identifier for the server or server group
associated with this transaction. This is the receiver
when a Request packet and the sender ...
... for reply, or retransmit. If a Response message, treat
this message transaction as idempotent.
MDM Message Delivery ...
... |S|G|R|R|T|G|G|I|T|Count| | Gap | -ity |S|S|S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PacketDelivery |
...
...
in responding to this Request.
Transaction Identifier for transaction, at least one greater than
...
...
Transaction Identifier for transaction, at least one greater than
the previously issued Request from this Client.
...
... |S|G|R|R|T|S|G|I|S|Count| | | -ity |S|S|S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PacketDelivery |
...
... Client, Version, Domain, Transaction
Match those in the Request packet group to which this is
...
...
STI 1 if this Response is using one or more of the
transaction identifiers skipped by the Client after the
...
... by the Client after the
Request to which this is a Response. STI in the Request
essentially allocates up to 256 transaction identifiers
for the Server to use in a run of Response packet ...
... groups that
this response is acknowledging in addition to the one
identified by the Transaction identifier.
...
... state record
(CSR) per (client,transaction) outstanding message transaction. Here is
a suggested set of fields.
...
... (CSR) per (client,transaction) outstanding message transaction. Here is
a suggested set of fields.
...
... queue.
TimeoutLimit User-specified time after which the message transaction
is aborted. The timeout is infinite if set to zero.
...
... with considerable benefit if the process is designed to block when it
issues a message transaction. In particular, by combining the two
descriptors, the implementation saves time because it only needs to
locate and queue ...
... Client State Record records the state of message transaction generated
by this host, identified by the (Client ...
... by this host, identified by the (Client, Transaction) values in the CSR.
As a client originating a transaction ...
... Transaction) values in the CSR.
As a client originating a transaction, it is in one of the following
states.
...
... state also includes any other state besides those associated with
issuing a message transaction.
+------------+
...
...
Send( mcb, timeout, segptr, segsize )
Initiate a message transaction to the server and request
message specified by mcb and return a response in mcb,
if it is received within the specified timeout period
...
... Get the next response sent to this client as part of the
current message transaction, returning the segment data,
if any, into the memory specified by segptr and segsize.
...
... We first describe some conventions and procedures used in the
description. A field of the received packet is indicated as (for
example) p.Transaction, for the Transaction field. Optional portions of
the code, such as the streaming handling code are prefixed with a "|" in
...
... description. A field of the received packet is indicated as (for
example) p.Transaction, for the Transaction field. Optional portions of
the code, such as the streaming handling code are prefixed with a "|" in
the first column.
...
... csr.RemoteDelivery, and code. If csr is NULL, use
p.Client, p.Transaction and p.PacketDelivery instead and
the global ReceiveSequenceNumber, if supported. This
function simplifies the description over calling
...
... csr.LocalTransaction, csr.LocalDelivery and code. Use
p.Client, P.Transaction and 0 for the clientId, transact
and delivery parameters if csr is NULL. This function
...
... segment if any.
Set SDA if sending appended data.
Flush queued replies from previous transaction, if any.
if local non-group server then
...
... address from the Response.
The ProbeEntity operation is handled as a separate message
transaction by the Client.
...
... stream interface incorporates a parameter to pass a responseHandler
procedure that is invoked when the message transaction completes.
StreamSend( mcb, timeout, segptr, segsize, responseHandler )
...
... Notes:
1. Each outstanding message transaction is represented by a CSR
queued on the root CSR for this client ...
...
2. A response must remain queued until the next message
transaction is invoked to filter out duplicates of this
response.
...
... NotifyServer(csr, p, STREAMING_NOT_SUPPORTED )
return STREAMED_RESPONSE
| Find csr corresponding to p.Transaction
| if none found then
| NotifyServer(csr, p, BAD_TRANSACTION ...
... Transaction
| if none found then
| NotifyServer(csr, p, BAD_TRANSACTION_ID )
| return
else
...
... | return
else
if csr.LocalTransaction not equal p.Transaction then
NotifyServer(csr, p, BAD_TRANSACTION_ID )
...
... if csr.LocalTransaction not equal p.Transaction then
NotifyServer(csr, p, BAD_TRANSACTION_ID )
return
endif
...
... | Find last packet group CSR from p.Server.
| if p.Transaction not
| lastcsr.RemoteTransaction+1 mod 2**32 then
| { Out of order ...
... Basically, a Response is accepted if there has been a Request
received locally from the same Client and same Transaction
that has not been responded to. In this case, the Response
is delivered to the Server or queued.
...
... segment data of
the Request was received. All subsequent NotifyVmtpClient
operations for this transaction should be set to acknowledge
a superset of the segment blocks in this packet. In
...
...
A client with a message transaction in progress has a single timer
corresponding to the first unacknowledged request message ...
... if csr.RetransCount > MaxRetrans(csr.Server) then
terminate Client's message transactions up to
and including the current message transaction.
...
... Client's message transactions up to
and including the current message transaction.
set return code to KERNEL_TIMEOUT
...
... no selective retransmission for idempotent message
transactions.
2. The current packet group ...
... cannot be retransmitted. However, duplicates are still
filtered and CSR can be reused for new message
transaction.
Processing Executing on behalf of the Client ...
... Client.
Forwarded The message transaction has been forwarded to another
Server that is to respond directly to the Client.
...
... it sends a Probe request (as a separate VMTP message transaction) to the
VMTP management module associated with the ...
... processing is complete, either the Response is sent and the CSR enters
the Responded state or the message transaction is forwarded and the CSR
enters the Forwarded state.
...
...
Receipt of a new Request from the same Client aborts the current
transaction, independent of its state, and initiates a new transaction
...
... aborts the current
transaction, independent of its state, and initiates a new transaction
unless the new Request is part of a run of message transactions. If it
...
... state, and initiates a new transaction
unless the new Request is part of a run of message transactions. If it
is part of a run of message transactions, the handling follows the state
diagram ...
... unless the new Request is part of a run of message transactions. If it
is part of a run of message transactions, the handling follows the state
diagram except the new Request is not Processed until there has been a
response sent to the previous transaction ...
... transactions, the handling follows the state
diagram except the new Request is not Processed until there has been a
response sent to the previous transaction.
...
... segment size in the segsize parameters. It also returns
the Client and Transaction for this message transaction
in the corresponding parameters. This procedure
...
... the Client and Transaction for this message transaction
in the corresponding parameters. This procedure
supports message semantics ...
... ForwardCall( requestmcb, segptr, segsize, forwardserver )
Forward the client transaction to the specified
forwardserver with the request specified by requestmcb.
This procedure does not return.
...
... return Request in reqmcb, segptr and segsize
and client and transaction id.
Wait on server's request queue for next request
...
...
Forwarding is logically initiating a new message transaction between the
Server (now acting as a Client) and the server to which the Request is
...
... Notes:
1. A Forward is logically a new call or message transaction. It
must be really implemented as a new message transaction if
...
... 1. A Forward is logically a new call or message transaction. It
must be really implemented as a new message transaction if
the original Request was multicast or secure (with the
...
... multicast or secure (with the
optional further refinement that it can be used with a secure
message transaction when the Server and ForwardServer are the
same principal and the Request was not multicast ...
... { Forwarded Request on local Client }
if csr.LocalTransaction != p.Transaction then return
if csr.State != AwaitingResponse then return
...
... if packet group complete then
handle as a local message transaction
return
Allocate and init CSR
...
... Allocate and init CSR
goto newTransaction
{ Otherwise part of current transaction }
{ Handle directly below. }n
if csr.RemoteTransaction = p.Transaction ...
... transaction }
{ Handle directly below. }n
if csr.RemoteTransaction = p.Transaction then
{ Matches current transaction }
...
... if csr.RemoteTransaction = p.Transaction then
{ Matches current transaction }
if OldForward(p.ForwardCount,csr.ForwardCount) then
return
...
... return
if p.ForwardCount > csr.ForwardCount then
{ New forwarded transaction }
goto newTransaction
...
... goto newTransaction
{ Otherwise part of current transaction }
if csr.State = ReceivingRequest then
...
... NotifyClient( csr, p, OK )
return
else if OldTransaction(csr.RemoteTransact,p.Transaction) then
return
{ Otherwise, a new message transaction ...
... Transaction) then
return
{ Otherwise, a new message transaction. }
newTransaction:
Abort handling of previous transactions ...
... group CSR from this client.
| if p.Transaction not lastcsr.RemoteTransaction+1 mod 2**32
| and not STIset(lastcsr) or
| p.Transaction ...
... Transaction not lastcsr.RemoteTransaction+1 mod 2**32
| and not STIset(lastcsr) or
| p.Transaction not lastcsr.RemoteTransaction+256 mod **32
| then
| { Out of order ...
... return
endif
{ Setup immediately as a new message transaction }
set csr.Server to p.Server
set csr.RemoteTransaction to p.Transaction ...
... transaction }
set csr.Server to p.Server
set csr.RemoteTransaction to p.Transaction-1
HandleRequest( csr, p, psize )
...
... 9 MSGTRANS_OVERFLOW
10 BAD_TRANSACTION_ID
11 STREAMING_NOT_SUPPORTED
...
... entity groups, probing to get
information about entities, and updating message transaction information
at the client or the server.
...
... authenticates the
Response as responding to the Request when
its EntityId, randomId and Transaction values
match those in the Probe request. The
...
... 1 Handles streamed Requests.
2 Can issue streamed message transactions
for clients.
...
... 4 Handles secure Requests.
8 Can issue secure message transactions.
The authdomain indicates the primary authentication
domain ...
... Update the state associated with the transaction
specified by client and transact, an entity ...
... entity identifier
and transaction identifier, respectively. This
operation is normally used only by another VMTP ...
... packets that are part of this packet
run. (The latter is applicable only for
streamed message transactions.)
BUSY The server was unable to accept the
...
... Request at this time. Retry later if
desired to continue with the message
transaction.
NONEXISTENT_ENTITY ...
... STREAMING_NOT_SUPPORTED
Server does not support multiple
outstanding message transactions from
the same Client, i.e. streamed message
...
... Update the server state associated with the transaction
specified by client and transact, an entity ...
... entity identifier
and transaction identifier, respectively. This
operation is normally used only by another VMTP ...
... its client identifier in the ProbeEntityBlock Request and a
transaction identifier of 0. As soon as it has allocated a
block of entity ...
... 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
...
... client stream is implemented by allocating a CSR for each outstanding
message transaction. A stream of transactions is handled similarly to
...
... message transaction. A stream of transactions is handled similarly to
multiple outstanding transactions from separate clients ...
... stream of transactions is handled similarly to
multiple outstanding transactions from separate clients except for the
interaction between consecutive numbered transactions ...
... 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 ...
... 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
...
... . Thus, streamed transactions from a given
Client are always performed in the order specified by the transaction
identifiers.
...
...
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
...
...
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
...
... 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 ...
... 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
...
... 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 ...
... 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.
...
... 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
...
... 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 ...
... entity group), the next
response to the current message transaction (if it arrives in less than
timeout milliseconds) is returned by
...
...
The request message for the next queued transaction request is returned
in mcb, plus the segment data of maximum length maxseglen, starting ...
... segment.
To complete a transaction, the reply specified by mcb is sent to the
client specified by the MCB using
...
... 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
...