You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1640 lines
62 KiB
1640 lines
62 KiB
<!-- This HTML file has been created by timdif2html 1.11
|
|
from wire-encoding.dif on 7 July 1998 -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>HTTP-NG Binary Wire Protocol</TITLE>
|
|
</HEAD>
|
|
<BODY TEXT=#000000 BGCOLOR=#ffffff>
|
|
<H3 align='right'>
|
|
<A HREF='http://www.w3.org/'><IMG border='0' align='left' alt='W3C' src='http://www.w3.org/Icons/WWW/w3c_home'></A>WD-HTTP-NG-wire-19980710
|
|
</H3>
|
|
<H1 align='center'>
|
|
HTTP-NG Binary Wire Protocol
|
|
</H1>
|
|
<H3 ALIGN=Center>
|
|
W3C Working Draft 10 July 1998
|
|
</H3>
|
|
<DL>
|
|
<DT>
|
|
This version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/1998/WD-HTTP-NG-wire-19980710">http://www.w3.org/TR/1998/WD-HTTP-NG-wire-19980710</A>
|
|
<DT>
|
|
Latest version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-wire">http://www.w3.org/TR/WD-HTTP-NG-wire</A>
|
|
<DT>
|
|
Authors:
|
|
<DD>
|
|
Bill Janssen, Xerox PARC,
|
|
<<A HREF="mailto:<janssen@parc.xerox.com>">janssen@parc.xerox.com</A>>
|
|
</DL>
|
|
<p><small><A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright'>Copyright</A>
|
|
© 1998 <A href='http://www.w3.org'>W3C</A> (<A href='http://www.lcs.mit.edu'>MIT</A>,
|
|
<A href='http://www.inria.fr/'>INRIA</A>, <A href='http://www.keio.ac.jp/'>Keio</A> ),
|
|
All Rights Reserved. W3C <A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer'>liability,</A>
|
|
<A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks'>trademark</A>,
|
|
<A href='http://www.w3.org/Consortium/Legal/copyright-documents.html'>document use
|
|
</A>and <A href='http://www.w3.org/Consortium/Legal/copyright-software.html'>software licensing </A>rules apply.
|
|
</small></p>
|
|
<H1>
|
|
1. Status of this Document
|
|
</H1>
|
|
<P>
|
|
This is a W3C Working Draft for review by W3C members and other interested
|
|
parties. It is a draft document and may be updated, replaced or obsoleted
|
|
by other documents at any time. It is inappropriate to use W3C Working Drafts
|
|
as reference material or to cite them as other than "work in progress". A
|
|
list of current W3C technical reports can be found at
|
|
<A HREF="http://www.w3.org/TR/">http://www.w3.org/TR</A>.
|
|
<P>
|
|
This document has been produced as part of the W3C HTTP-ng Activity. This
|
|
is work in progress and does not imply endorsement by, or the consensus of,
|
|
either W3C or members of the HTTP-ng Protocol Design Working Group. We expect
|
|
the document to evolve as we get more data from the Web Characterization
|
|
Group describing the current state of the Web.
|
|
<P>
|
|
This document describes a binary `on-the-wire' protocol to be used when sending
|
|
HTTP-ng operation invocations or terminations across a network connection.
|
|
It is part of a suite of documents describing the HTTP-NG design and prototype
|
|
implementation:
|
|
<UL>
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/1998/WD-HTTP-NG-goals">HTTP-NG Short- and Longterm Goals</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-architecture">HTTP-NG Architectural Model</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-wire">HTTP-NG Wire Protocol</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-interfaces">The Classic Web Interfaces in HTTP-NG</A>,
|
|
WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-mux">The MUX Protocol</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/NOTE-HTTP-NG-testbed">Description of the HTTP-NG Testbed</A>, Note
|
|
</UL>
|
|
<P>
|
|
Please send comments on this specification to
|
|
<<A HREF="mailto:www-http-ng-comments@w3.org">www-http-ng-comments@w3.org</A>>.
|
|
<H1>
|
|
2. Syntax Used in this Document
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX1"></A> <A NAME="IDX2"></A>
|
|
<P>
|
|
Two data description languages are used in this document. The first, called
|
|
ISL, is an abstract language for defining data types and interfaces. It is
|
|
described in
|
|
<A HREF="ftp://ftp.parc.xerox.com/pub/ilu/2.0a12/manual-html/manual_2.html">the
|
|
ILU manual</A>. The second is a pseudo-C syntax. It should be interpreted
|
|
as C data structure layouts without any automatic padding to size boundaries,
|
|
and allowing arbitrary bit-size limits on structs and unions as well as on
|
|
ints and enums. Each use of ISL and pseudo-C is marked as to which language
|
|
is being used.
|
|
<P>
|
|
<A NAME="IDX3"></A> <A NAME="IDX4"></A>
|
|
<H1>
|
|
3. Model of Operation
|
|
</H1>
|
|
<P>
|
|
This protocol assumes a particular model of operation based on conventional
|
|
RPC technology, with certain variations. The basic idea is that clients make
|
|
use of services exported from a server by invoking operations on objects
|
|
resident in that server. The client is connected to the server by a
|
|
<DFN>connection</DFN>, which carries operation invocation requests from the
|
|
client (known as the <DFN>caller</DFN>) to the server (known as the
|
|
<DFN>callee</DFN>), and operation results from the callee back to the caller.
|
|
Multiple connections can exist simultaneously between the same client and
|
|
server. The connection has state associated with it, which allows the caller
|
|
and callee to use shorthand notations for some of the data passed to the
|
|
other party.
|
|
<P>
|
|
Two RPC messages are defined by this protocol: the Request, which is used
|
|
by the caller to invoke an operation on the callee, and the Reply, which
|
|
is used to transfer operation results from the callee to the caller. Every
|
|
Reply message is associated with a particular Request message, but not every
|
|
Request message has a Reply message associated with it. Connections are
|
|
directional; operation invocation Requests always flow from the caller to
|
|
the callee; Replies always flow from the callee to the caller. In addition
|
|
to the RPC messages, several control messages are defined for this protocol.
|
|
These control messages are used to improve the efficiency and robustness
|
|
of the connection. They are intended to be generated and consumed by the
|
|
implementation of the wire protocol, and should have no direct effect on
|
|
the applications using the protocol. <A NAME="IDX5"></A> <A NAME="IDX6"></A>
|
|
<A NAME="IDX7"></A> <A NAME="IDX8"></A> <A NAME="IDX9"></A>
|
|
<P>
|
|
A Request message indicates two important elements, the <DFN>operation</DFN>
|
|
and the <DFN>discriminant object</DFN>, or discriminant; it also contains
|
|
data values which are the input parameters to the operation. The model used
|
|
here assumes that operations are grouped into sets, the elements of which
|
|
have a well-defined ordering; each operation set is called an
|
|
<DFN>interface</DFN>. It further assumes that an interface can be identified
|
|
by a URN which also a UUID; and that each operation in an interface can be
|
|
identified with the ordinal number of the operation within the ordering of
|
|
the elements of the interface. It assumes that every discriminant object
|
|
can be identified with an <DFN>object ID</DFN>, also a URN and UUID. It provides
|
|
for the fact that, with most distributed object systems, all of the discriminants
|
|
available at a particular server share a common prefix to their object ID;
|
|
this is called the <DFN>server ID</DFN>. Note that this characteristic is
|
|
not required, but the protocol provides an efficiency optimization for the
|
|
case where it is true. In such a case, we call the portion of the object
|
|
ID <EM>not</EM> contained in the server ID the <DFN>instance handle</DFN>.
|
|
Each request has an implicit connection-specific serial number associated
|
|
with it; serial numbers begin with the value one (1), and have a maximum
|
|
value of 16777215. When the maximum serial number of a connection has been
|
|
reached, the connection must be terminated, and further operations must be
|
|
invoked over a new connection.
|
|
<P>
|
|
A Reply message indicates the termination status of the operation, provides
|
|
information about synchronization, and may contain data values which are
|
|
output parameters or `return values' from the operation. It contains an explicit
|
|
serial number to indicate which Request it is a reply to. Replies may either
|
|
indicate successful completion of the operation, or several different kinds
|
|
of exceptional termination; if an exception is signalled, additional information
|
|
is passed to indicate which of the possible exceptions for the operation
|
|
was raised. <A NAME="IDX10"></A> <A NAME="IDX11"></A> <A NAME="IDX12"></A>
|
|
<A NAME="IDX13"></A>
|
|
<P>
|
|
The model assumes that the messages are carried back and forth between the
|
|
two parties by a <DFN>transport</DFN> subsystem. It requires that the transport
|
|
subsystem be <DFN>reliable</DFN>, <DFN>sequenced</DFN>, and
|
|
<DFN>message-oriented</DFN>. By reliable, we mean that after a message is
|
|
handed to the transport, the transport will either deliver it to the other
|
|
party, or will signal an error if its reliable delivery cannot be ascertained.
|
|
By sequenced, we mean that the transport will deliver messages to the other
|
|
party in the same order in which the sender handed them to the transport.
|
|
By message-oriented, we mean that the transport will provide indication of
|
|
the beginning and ending of the messages, without reference to any data encoded
|
|
inside the message. An example of this type of transport would be the record
|
|
marking defined in
|
|
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1831.txt">Internet
|
|
RFC 1831</A> used with TCP/IP.
|
|
<P>
|
|
<H1>
|
|
4. Global Issues
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX14"></A> <A NAME="IDX15"></A>
|
|
<P>
|
|
<H2>
|
|
4.1. Byte Order
|
|
</H2>
|
|
<P>
|
|
All values use `network standard' byte order, i.e. big-endian, because all
|
|
Internet protocols use it. If in the future this becomes a problem for the
|
|
Internet, this protocol will be affected by whatever solution is used to
|
|
solve the problem in the wider Internet context. Note that the data marshalling
|
|
format defined in Internet RFC 1832, which this protocol incorporates by
|
|
reference, is also defined to be a big-endian protocol. <A NAME="IDX16"></A>
|
|
<A NAME="IDX17"></A>
|
|
<P>
|
|
<H2>
|
|
4.2. Alignment and Padding
|
|
</H2>
|
|
<P>
|
|
The marshalled form of each value begins on a 32-bit boundary. The marshalled
|
|
form of each value is padded-after, if necessary, to the next 32-bit boundary.
|
|
The padding bits may be either 0 or 1 in any combination.
|
|
<A NAME="IDX18"></A>
|
|
<P>
|
|
<H2>
|
|
4.3. Marshalling Format
|
|
</H2>
|
|
<P>
|
|
Marshalling is via the XDR format specified in
|
|
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1832.txt">Internet
|
|
RFC 1832</A>. It could be argued that this format is inexcusably wasteful
|
|
with certain value types, such as boolean (32 bits) or byte (32 bits), and
|
|
that a 16-bit or 8-bit oriented format should be designed and used in its
|
|
place. However, the argument of using an existing Internet standard for this
|
|
purpose, rather than inventing a new one, is a strong one; a new format should
|
|
only be defined if measurement of the overhead shows gross waste.
|
|
<A NAME="IDX19"></A>
|
|
<P>
|
|
<H2>
|
|
4.4. Security
|
|
</H2>
|
|
<P>
|
|
This protocol assumes that security provisions are made either at some level
|
|
above it, typically in the application interfaces, or at some level below
|
|
it, typically by use of a secure transport mechanism. It contains no
|
|
protocol-level mechanisms for providing or assuring any of the concerns normally
|
|
related to security. <A NAME="IDX20"></A>
|
|
<P>
|
|
<H2>
|
|
4.5. Session Context
|
|
</H2>
|
|
<P>
|
|
Unlike some previous protocols, this protocol is <DFN>session-oriented</DFN>.
|
|
That means that individual messages are sent in the context of a session,
|
|
and are context-sensitive. This context-sensitivity allows session-wide
|
|
compression. However, to support various kinds of marshalling architectures
|
|
in implementations of this system, all marshalling can be done in a
|
|
context-insensitive fashion, at the expense of sending additional bytes across
|
|
the wire. However, unmarshalling implementations must always be capable of
|
|
tracking and using context-sensitive information.
|
|
<P>
|
|
<H1>
|
|
5. Utility types
|
|
</H1>
|
|
<P>
|
|
The following data structures are defined in pseudo-C: <A NAME="IDX21"></A>
|
|
<PRE>
|
|
typedef enum {
|
|
False = 0,
|
|
True = 1
|
|
} Boolean;
|
|
|
|
<A NAME="IDX22"></A>typedef enum {
|
|
InitializeConnection = 0,
|
|
TerminateConnection = 1,
|
|
DefaultCharset = 2
|
|
} ControlMsgType;
|
|
|
|
<A NAME="IDX23"></A>typedef enum {
|
|
Success = 0,
|
|
UserException = 1, /* occurred during operation */
|
|
SystemExceptionBefore = 2, /* occurred before beginning operation */
|
|
SystemExceptionAfter = 3 /* occurred after beginning operation */
|
|
} ReplyStatus;
|
|
|
|
<A NAME="IDX24"></A>typedef struct {
|
|
Boolean cached_disc : 1; /* True if cached object key */
|
|
union {
|
|
struct {
|
|
Boolean cache_key : 1; /* True if both sides cache it */
|
|
unsigned key_len : 13; /* length of key bytes */
|
|
} uncached_key;
|
|
unsigned cache_index : 14; /* cache index if cached */
|
|
} v;
|
|
} DiscriminantID;
|
|
|
|
<A NAME="IDX25"></A>typedef struct {
|
|
Boolean cached_op : 1; /* True if cached id */
|
|
union {
|
|
struct {
|
|
Boolean cache_operation : 1; /* True if should be cached */
|
|
unsigned method_id : 13; /* method index */
|
|
} uncached_op_info;
|
|
unsigned cache_index : 14; /* cache index if "cached_op" set */
|
|
} v;
|
|
} OperationID;
|
|
|
|
<A NAME="IDX26"></A>typedef enum {
|
|
MangledMessage = 0, /* bad protocol synchronization */
|
|
ProcessFinished = 1, /* sending party has `exitted' */
|
|
ResourceManagement = 2, /* transient close */
|
|
WrongCallee = 3, /* bad server ID received */
|
|
MaxSerialNumber = 4 /* the maximum serial number was used */
|
|
} TerminationCause;
|
|
|
|
<A NAME="IDX27"></A>typedef struct {
|
|
unsigned major : 4;
|
|
unsigned minor : 4;
|
|
} ProtocolVersion;
|
|
|
|
<A NAME="IDX28"></A>typedef unsigned Unused;
|
|
</PRE>
|
|
<H1>
|
|
6. Messages
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX29"></A> <A NAME="IDX30"></A> <A NAME="IDX31"></A>
|
|
<A NAME="IDX32"></A>
|
|
<P>
|
|
Only a few messages are defined. The <CODE>InitializeConnection</CODE> message
|
|
is used by the caller to verify that it has connected to the right server,
|
|
and that it is using the correct version of the wire protocol. The
|
|
<CODE>DefaultCharset</CODE> message allows both sides to independently define
|
|
a default value for string charsets. The <CODE>Request</CODE> message causes
|
|
an operation to be started on the remote server. The <CODE>Reply</CODE> message
|
|
is sent from the server to the client to inform it of the completion status
|
|
of the operation, and to convey any result values. The
|
|
<CODE>TerminateConnection</CODE> message allows either side to indicate graceful
|
|
shutdown of a connection.
|
|
<P>
|
|
<A NAME="IDX33"></A>
|
|
<H2>
|
|
6.1. Extension Headers
|
|
</H2>
|
|
<P>
|
|
This protocol uses a feature called an <DFN>extension header</DFN> to provide
|
|
for extensibility and tailorability. Features such as serialization contexts
|
|
or global thread identifiers may be implemented via this feature. An extension
|
|
header is an encapsulated value of the ISL type <CODE>ExtensionHeader</CODE>.
|
|
Each request message and reply message may contain a value of type
|
|
<CODE>ExtensionHeaderList</CODE>, which contains a number of extension headers.
|
|
The following ISL fragment decribes the types
|
|
<CODE>ExtensionHeaderList</CODE> and <CODE>ExtensionHeader</CODE>:
|
|
<A NAME="IDX35"></A> <A NAME="IDX36"></A> <A NAME="IDX34"></A>
|
|
<PRE>
|
|
INTERFACE HTTP-ng-w3ng IMPORTS HTTP-ng END BRAND "http-ng.w3.org";
|
|
...
|
|
TYPE SimpleString = STRING LANGUAGE "i-default" LIMIT 0xFFFF;
|
|
TYPE CinfoString = STRING LANGUAGE "i-httpngcinfo" LIMIT 0xFFFF;
|
|
TYPE ExtensionHeader = RECORD
|
|
name : HTTP-ng.UUIDString,
|
|
value : PICKLE
|
|
END;
|
|
TYPE ExtensionHeaderList = SEQUENCE OF ExtensionHeader;
|
|
...
|
|
</PRE>
|
|
<P>
|
|
<H2>
|
|
6.2. <CODE>Request</CODE> Message
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX37"></A>
|
|
<P>
|
|
Request header (pseudo-C):
|
|
<P>
|
|
<A NAME="IDX38"></A>
|
|
<PRE>
|
|
typedef struct {
|
|
Boolean control_msg : 1; /* == FALSE */
|
|
Boolean ext_hdr_present : 1; /* True if ext hdr list present */
|
|
OperationID operation_id : 15; /* identifies operation */
|
|
DiscriminantID object_key : 15; /* identifies discriminant */
|
|
} RequestMsgHeader /* 4 bytes total */
|
|
</PRE>
|
|
<P>
|
|
The actual message consists of the following sections:
|
|
<P>
|
|
[ <CODE>RequestMsgHeader</CODE> ]<BR>
|
|
[ extension header list, if any ]<BR>
|
|
[ XDR <CODE>string</CODE> containing object type ID of object type defining
|
|
operation, if not cached ]<BR>
|
|
[ bytes of <VAR>object_key</VAR>, if not cached, padded to 4 byte boundary
|
|
]<BR>
|
|
[ explicit input parameter values, if any, padded to a 4 byte boundary ]<BR>
|
|
<A NAME="IDX39"></A>
|
|
<P>
|
|
The <VAR>operation_id</VAR> contains either a connection-specific 14-bit
|
|
cache index, or a 13-bit method id (the zero-based ordinal position of the
|
|
method in the ISL declaration of the object type in which the operation is
|
|
defined) of the operation. If the method id is given, an additional value,
|
|
an XDR <CODE>string</CODE> value containing the object type ID of the object
|
|
type in which the operation is defined, is also passed. This means that this
|
|
protocol will not support interfaces in which object types have more than
|
|
8192 methods directly defined. <A NAME="IDX40"></A>
|
|
<P>
|
|
The <VAR>object_key</VAR> is either a 14-bit connection-specific cache index,
|
|
or the length of a variable length octet sequence of 8192 or fewer bytes
|
|
containing the service-point-relative name for the object (the
|
|
<VAR>instance-handle</VAR> of the URL). The object key value of <CODE>{ False,
|
|
False, 0 }</CODE>, normally a zero byte variable length object key, is reserved
|
|
for use by the protocol. The <VAR>object_key</VAR> is marshalled onto the
|
|
transport as an XDR value of type <CODE>fixed-length opaque data</CODE>,
|
|
where the length is that specified in the <CODE>v.key_len</CODE> field of
|
|
the <VAR>object_key</VAR>.
|
|
<P>
|
|
<A NAME="IDX41"></A> <A NAME="IDX42"></A> <A NAME="IDX43"></A>
|
|
<H3>
|
|
6.2.1 Operation and Object Memoizing
|
|
</H3>
|
|
<P>
|
|
Callers may reduce the size of messages by memoizing operation IDs and object
|
|
IDs that are passed in the connection. This is done by the caller setting
|
|
the <CODE>cache_key</CODE> (for object IDs) or <CODE>cache_operation</CODE>
|
|
(for operation IDs) bit in the <CODE>DiscriminantID</CODE> or
|
|
<CODE>OperationID</CODE> struct when the object key or operation ID is first
|
|
sent. Each side must then assign the next available index to that object
|
|
or operation. The space of operations is separate from the space of object
|
|
ids, so that a total of 16383 possible values is available for memoizing
|
|
of discriminant objects, and 16383 different possible values for memoizing
|
|
of operations.
|
|
<P>
|
|
Note that the index is passed implicitly, so both sides of the connection
|
|
must synchronize their use of indices.
|
|
<P>
|
|
A shared set of indices may be loaded into the connection by some mechanism
|
|
before any messages are sent. This specification does not define a mechanism
|
|
for doing so.
|
|
<P>
|
|
<H2>
|
|
6.3. <CODE>Reply</CODE> Message
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX44"></A>
|
|
<P>
|
|
Reply header (pseudo-C):
|
|
<P>
|
|
<A NAME="IDX45"></A>
|
|
<PRE>
|
|
typedef struct {
|
|
Boolean control_msg : 1; /* == FALSE */
|
|
Boolean ext_hdr_present : 1; /* True if ext hdr list present */
|
|
ReplyStatus : 2;
|
|
Unused reply_1 : 4;
|
|
unsigned serial_no : 24; /* serial # from Request */
|
|
} ReplyMsgHeader; /* 4 bytes total */
|
|
</PRE>
|
|
<P>
|
|
The actual message consists of the following fields:
|
|
<P>
|
|
[ <CODE>ReplyMsgHeader</CODE> ]<BR>
|
|
[ extension header list, if any ]<BR>
|
|
[ exception ID (32-bit unsigned), if any ]<BR>
|
|
[ explicit output parameter values, if any, padded to 4 byte boundary ]<BR>
|
|
<P>
|
|
<H2>
|
|
6.4. <CODE>InitializeConnection</CODE> Message
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX46"></A>
|
|
<P>
|
|
InitializeConnection header (pseudo-C): <A NAME="IDX47"></A>
|
|
<P>
|
|
<PRE>
|
|
typedef struct {
|
|
Boolean control_msg : 1; /* == TRUE */
|
|
ControlMsgType msg_type : 3; /* == InitializeConnection */
|
|
Unused verify_1 : 4;
|
|
ProtocolVersion version : 8; /* what version of the protocol? */
|
|
unsigned server_id_len : 16; /* length of server ID */
|
|
} InitializeConnectionMsgHeader;
|
|
</PRE>
|
|
<P>
|
|
The actual message consists of the following fields:
|
|
<P>
|
|
[ <CODE>InitializeConnectionMsgHeader</CODE> ]<BR>
|
|
[ <CODE>server_id_len</CODE>-length server ID for supposed callee, padded
|
|
to 4-byte boundary ]<BR>
|
|
<P>
|
|
This message is sent from caller to callee as the first message of the
|
|
connection. It is used to pass the server ID of the connection from client
|
|
to server, so that both sides understand what the omitted prefix portion
|
|
of discriminant IDs is. If the server ID received by the callee is not the
|
|
correct server ID for the callee (i.e., the callee has objects which do not
|
|
have that prefix in their object IDs), the callee should terminate the
|
|
connection, with the appropriate reason. The server ID is passed as an XDR
|
|
<CODE>fixed-length opaque data</CODE> value of the length specified in
|
|
<CODE>server_id_len</CODE>.
|
|
<P>
|
|
<H2>
|
|
6.5. <CODE>TerminateConnection</CODE> Message
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX48"></A>
|
|
<P>
|
|
TerminateConnection header (pseudo-C):
|
|
<P>
|
|
<A NAME="IDX49"></A>
|
|
<PRE>
|
|
typedef struct {
|
|
Boolean control_msg : 1; /* == TRUE */
|
|
ControlMsgType msg_type : 3; /* == TerminateConnection */
|
|
TerminationCause cause: 4; /* why connection terminated */
|
|
unsigned serial_no : 24; /* last request processed/sent */
|
|
} TerminateConnectionMsgHeader;
|
|
</PRE>
|
|
<P>
|
|
<A NAME="IDX50"></A>
|
|
<P>
|
|
The actual message consists simply of the header; it provides for graceful
|
|
connection shutdown. It is sent either from the caller to the callee, or
|
|
from the callee to the caller, and informs the other party that it is cancelling
|
|
the connection, for one of these reasons:
|
|
<OL>
|
|
<LI>
|
|
A badly formatted message has arrived from the other party, and protocol
|
|
sychronization is believe lost, or, the caller has sent a
|
|
<CODE>InitializeConnection</CODE> message with the wrong major version for
|
|
the protocol;
|
|
<LI>
|
|
This party (process, thread, whatever) is going away, and the other party
|
|
should not attempt to reconnect to it;
|
|
<LI>
|
|
This connection is being terminated due to active resource management; the
|
|
other party should attempt to reconnect if it needs to -- this reason is
|
|
typically only useful from callee to caller;
|
|
<LI>
|
|
The caller has sent a <CODE>InitializeConnection</CODE> message with the
|
|
wrong server ID;
|
|
<LI>
|
|
The caller has used the maximum serial number available for this connection.
|
|
</OL>
|
|
<P>
|
|
The <CODE>serial_no</CODE> field contains the serial number of the last message
|
|
completely processed by the caller (when <CODE>TerminateConnection</CODE>
|
|
is sent from caller to callee), or the serial number of the last message
|
|
sent by the callee (when sent from callee to caller). No further messages
|
|
should be sent on the connection by a sender of a
|
|
<CODE>TerminateConnection</CODE> message after it has been sent, or by a
|
|
receiver of <CODE>TerminateConnection</CODE> messsage after it has been received.
|
|
<P>
|
|
<H2>
|
|
6.6. <CODE>DefaultCharset</CODE> Message
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX51"></A>
|
|
<P>
|
|
DefaultCharset header (pseudo-C):
|
|
<P>
|
|
<A NAME="IDX52"></A>
|
|
<PRE>
|
|
typedef struct {
|
|
Boolean control_msg : 1; /* == TRUE */
|
|
ControlMsgType msg_type : 3; /* == DefaultCharset */
|
|
Unused bits_12: 12; /* unused */
|
|
unsigned charset_mibenum : 16; /* default charset */
|
|
} DefaultCharsetMsgHeader;
|
|
</PRE>
|
|
<P>
|
|
This message is sent by either side of a connection to establish a default
|
|
charset for subsequent messages sent by that side of the connection. The
|
|
charset defines how string values are marshalled as octet sequences. The
|
|
default charset defines the default marshalling, unless overridden by an
|
|
explicit charset in a string value. Each side of the connection may establish
|
|
a default charset independently of the other side of the connection; the
|
|
default charset only applies to string values in messages coming from that
|
|
side. A new value of the default charset may be established at any time by
|
|
sending another <CODE>DefaultCharset</CODE> message.
|
|
<P>
|
|
<H1>
|
|
7. Data Marshalling
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX53"></A> <A NAME="IDX54"></A> <A NAME="IDX55"></A>
|
|
<P>
|
|
The data value format used for parameters is the XDR format specified in
|
|
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1832.txt">Internet
|
|
RFC 1832</A>. However, we extend the XDR specification with one additional
|
|
type, called <DFN>flagged variable-length opaque data</DFN>. It is similar
|
|
to XDR's regular variable-length opaque data, except that the high-order
|
|
bit of the length field is used as a flag bit, instead of being part of the
|
|
length. This means that flagged variable-length opaque data can only carry
|
|
opaque data of lengths less than or equal to (2**31)-1.
|
|
<PRE>
|
|
0 1 2 3 4 5 ...
|
|
++----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|
|
flag -->|| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
|
|
bit ++----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|
|
||<------31 bits------->|<------n bytes------>|<---r bytes--->|
|
|
|<----n+r (where (n+r) mod 4 = 0)---->|
|
|
FLAGGED VARIABLE-LENGTH OPAQUE
|
|
</PRE>
|
|
<P>
|
|
<H2>
|
|
7.1. Boolean Type
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX56"></A>
|
|
<P>
|
|
Values of type <CODE>BOOLEAN</CODE> are passed as XDR <CODE>bool</CODE>.
|
|
<A NAME="IDX57"></A>
|
|
<P>
|
|
<H2>
|
|
7.2. Enumeration Types
|
|
</H2>
|
|
<P>
|
|
Values of enumeration types are passed as XDR <CODE>enum</CODE>. Each enumeration
|
|
value is assigned its ordinal value as it appears in the declaration of the
|
|
enumeration type, starting with the value `one'. <A NAME="IDX58"></A>
|
|
<P>
|
|
<H2>
|
|
7.3. Numeric Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX59"></A> <A NAME="IDX60"></A>
|
|
<H3>
|
|
7.3.1. Fixed-point Types
|
|
</H3>
|
|
<P>
|
|
Values of fixed-point types are passed by passing the value of the numerator.
|
|
We define a number of special cases for efficient marshalling of common integer
|
|
types, as well as a general case for passing values of fixed-point types
|
|
that are not covered by the special cases.
|
|
<P>
|
|
Special cases:<BR>
|
|
<UL>
|
|
<LI>
|
|
<B>32-bit integer</B>: Fixed-point values with a minimum-numerator value
|
|
greater than or equal to -2147483648 and with a minimum numerator value less
|
|
than or equal to 2147483647 are passed as XDR <CODE>integer</CODE>.
|
|
<LI>
|
|
<B>32-bit unsigned integer</B>: Fixed-point values with a minimum-numerator
|
|
value greater than or equal to 0 and with a maximum numerator less than or
|
|
equal to 4294967295 are passed as XDR <CODE>unsigned integer</CODE>.
|
|
<LI>
|
|
<B>64-bit integer</B>: Fixed-point values with a with a minimum numerator
|
|
value greater than or equal to -9223372036854775808 and with a maximum numerator
|
|
less than or equal to 9223372036854775807are passed as XDR <CODE>hyper
|
|
integer</CODE>.
|
|
<LI>
|
|
<B>64-bit unsigned integer</B>: Fixed-point values with a minimum-numerator
|
|
value greater than or equal to 0 and with a maximum numerator value less
|
|
than or equal to 18446744073709551615 are passed as XDR <CODE>unsigned hyper
|
|
integer</CODE>.
|
|
</UL>
|
|
<P>
|
|
General case:
|
|
<P>
|
|
The numerator of the value is passed as XDR <CODE>flagged variable-length
|
|
opaque data</CODE>, with the bytes of the data containing the value expressed
|
|
as a base-256 number, in big-endian order; that is, with the most significant
|
|
digit of the value first. The flag bit is used to carry the sign; the flag
|
|
bit is 0 for a positive number or zero, and 1 for a negative number.
|
|
<P>
|
|
<H3>
|
|
7.3.2. Floating-point Types
|
|
</H3>
|
|
<P>
|
|
We define a number of special cases for efficient marshalling of common
|
|
floating-point types, as well as a general case for passing values of
|
|
floating-point types that are not covered by the special cases.
|
|
<P>
|
|
Special cases:<BR>
|
|
<UL>
|
|
<LI>
|
|
<B>IEEE single</B>: floating point types matching the IEEE 32-bit floating-point
|
|
format (that is, with the parameters significand-size=24, exponent-base=2,
|
|
maximum-exponent-value=127, minimum-exponent-value=-126, has-Not-A-Number=TRUE,
|
|
has-Infinity=TRUE, denormalized-value-allowed=TRUE, and has-signed-zero=TRUE)
|
|
are passed as XDR <CODE>floating-point</CODE>.
|
|
<LI>
|
|
<B>IEEE double</B>: floating point types matching the IEEE 64-bit floating-point
|
|
format (that is, with the parameters significand-size=53, exponent-base=2,
|
|
maximum-exponent-value=1023, minimum-exponent-value=-1022, has-Not-A-Number=TRUE,
|
|
has-Infinity=TRUE, denormalized-value-allowed=TRUE, and has-signed-zero=TRUE)
|
|
are passed as XDR <CODE>double-precision floating-point</CODE>.
|
|
<LI>
|
|
<B>Intel extended double</B>: floating point types matching the Intel IEEE
|
|
floating-point-compliant extended double floating-point format (that is,
|
|
with the parameters significand-size=64, exponent-base=2,
|
|
maximum-exponent-value=16383, minimum-exponent-value=--16382,
|
|
has-Not-A-Number=TRUE, has-Infinity=TRUE, denormalized-value-allowed=TRUE,
|
|
and has-signed-zero=TRUE), are passed as a 12-byte value of XDR
|
|
<CODE>fixed-length opaque data</CODE>, containing the floating-point value
|
|
in the format specified in the UNIX System V Application Binary Interface
|
|
Intel 386 Processor Supplement (Intel ABI) document: the 63 bits of the fraction
|
|
occupy the first 7 bytes in little-endian order plus the low seven bits of
|
|
the eighth byte; the 1 bit explicit leading significand bit occupies the
|
|
high-order bit of the eighth byte; the 15 bits of the exponent occupy the
|
|
ninth byte and the low-order bits of the tenth byte, in little-endian order;
|
|
the sign bit occupies the high-order bit of the tenth byte; the eleventh
|
|
and twelfth bytes are unused, and should contain zero values.
|
|
<LI>
|
|
<B>SPARC & PowerPC extended double</B>: floating point types matching
|
|
the XDR quadruple-precision floating-point format (that is, with the parameters
|
|
significand-size=113, exponent-base=2, maximum-exponent-value=16383,
|
|
minimum-exponent-value=-16382, has-Not-A-Number=TRUE, has-Infinity=TRUE,
|
|
denormalized-value-allowed=TRUE, and has-signed-zero=TRUE), which is the
|
|
form of extended double floating-point used by PowerPC and SPARC processors,
|
|
are passed as XDR <CODE>quadruple-precision floating-point</CODE>.
|
|
</UL>
|
|
<P>
|
|
General case:
|
|
<P>
|
|
Values of floating-point types not matching the special cases identified
|
|
above are passed as a value of the XDR struct type
|
|
<CODE>GeneralFloatingPointValue</CODE>, which has the following definition:
|
|
<A NAME="IDX62"></A> <A NAME="IDX63"></A> <A NAME="IDX61"></A>
|
|
<PRE>
|
|
/* XDR */
|
|
enum { Normal = 1, NotANumber = 2, Infinity = 3 } FloatingPointValueType;
|
|
struct {
|
|
flagged opaque FixedPointSignAndSignificand<>;
|
|
flagged opaque FixedPointExponent<>;
|
|
} NormalFloatingPointValue;
|
|
union switch (FloatingPointValueType disc) {
|
|
case Normal: NormalFloatingPointValue value;
|
|
case NotANumber: void;
|
|
case Infinity: void;
|
|
} GeneralFloatingPointValue;
|
|
</PRE>
|
|
<P>
|
|
The two fields of the <CODE>NormalFloatingPointValue</CODE> struct each contain
|
|
an on-the-wire representation of a fixed-point value of the fixed-point type
|
|
(denominator=1, no-mininum-numerator, no-maximum-numerator). The
|
|
<CODE>FixedPointSignAndSignificand</CODE> field contains the sign of the
|
|
floating-point value as the sign, and the actual significand as the absolute
|
|
value of the fixed-point value. The <CODE>FixedPointExponent</CODE> field
|
|
contains the exponent of the floating-point value.
|
|
<P>
|
|
<H2>
|
|
7.4. String Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX64"></A>
|
|
<P>
|
|
Each string value sent in this protocol has a <DFN>charset</DFN> [RFC 2278]
|
|
associated with it, identified by the charset's IANA-assigned MIBEnum value.
|
|
Each side of a session may establish a <DFN>default charset</DFN> by sending
|
|
the <CODE>DefaultCharset</CODE> message. String values that use the default
|
|
character set do not contain explicit charset information; string values
|
|
that use a charset other than the default charset contain the MIBEnum value
|
|
for the charset, along with the bytes of the string.
|
|
<P>
|
|
We send a string value as a value of XDR <CODE>flagged variable-length opaque
|
|
data</CODE>. If the flag bit is 1, the first two bytes of the string value
|
|
are the MIBEnum of the charset, high-order byte first; the remaining bytes
|
|
are the bytes of the string. If the flag bit is 0, the bytes of opaque data
|
|
simply contain the bytes of the string; the charset is the default charset
|
|
for the session. It is a marshalling error to send a string value with a
|
|
flag bit of 0 over a session for which no default charset has been established.
|
|
To avoid context-sensitivity in marshalling a string, it is always valid
|
|
to marshal a string with an explicit charset value, even if the charset value
|
|
is the same as the default charset for the session. When marshalling a string
|
|
into a pickle, the charset should always be explicitly included.
|
|
<P>
|
|
<H2>
|
|
7.5. Sequence Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX65"></A> <A NAME="IDX66"></A>
|
|
<P>
|
|
Values of sequence types are passed as XDR <CODE>variable-length arrays</CODE>,
|
|
with one exception: Sequences of any fixed-point type with a minimum numerator
|
|
greater than or equal to 0, and a maximum numerator less than or equal to
|
|
255, are passed as XDR <CODE>variable-length opaque data</CODE>, with one
|
|
numerator value per octet.
|
|
<P>
|
|
<H2>
|
|
7.6. Array Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX67"></A> <A NAME="IDX68"></A>
|
|
<P>
|
|
Values of array types are passed as XDR <CODE>fixed-length arrays</CODE>,
|
|
with one exception: Arrays of any fixed-point type with a minimum numerator
|
|
greater than or equal to 0, and a maximum numerator less than or equal to
|
|
255, are passed as XDR <CODE>fixed-length opaque data</CODE>, with one numerator
|
|
value per octet. Values of array types are passed as XDR <CODE>fixed-length
|
|
arrays</CODE>, with one exception:
|
|
<P>
|
|
<H2>
|
|
7.7. Record Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX69"></A>
|
|
<P>
|
|
Values of record types are passed as XDR <CODE>struct</CODE>.
|
|
<P>
|
|
<H2>
|
|
7.8. Union Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX70"></A>
|
|
<P>
|
|
Values of union types are passed as XDR <CODE>union</CODE>, with the union
|
|
discriminant being the zero-based ordinal value for the encapsulated value's
|
|
type.
|
|
<P>
|
|
<H2>
|
|
7.9. Pickle Type
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX71"></A>
|
|
<P>
|
|
A pickle is passed as an XDR <CODE>variable-length opaque data</CODE>, containing
|
|
the type ID of the pickled value's type, followed by the XDR-marshalled pickled
|
|
value. To save pickle space for common value types used in metadata, we define
|
|
a packed format for the type ID marshalling. A type ID is marshalled into
|
|
a pickle as a 32-bit header, in an XDR <CODE>unsigned integer</CODE>, possibly
|
|
followed by an XDR <CODE>fixed-length opaque data</CODE>, containing the
|
|
string form of the type ID of the pickled type. The header has the following
|
|
internal structure:
|
|
<PRE>
|
|
/* Pseudo-C */
|
|
typedef struct {
|
|
unsigned version : 8;
|
|
PickleTypeKind type_kind : 8;
|
|
unsigned type_id_len : 16;
|
|
} TypeIDHeader;
|
|
</PRE>
|
|
<P>
|
|
The <CODE>version</CODE> field gives the version number of the pickle format;
|
|
the <CODE>type_kind</CODE> field contains a value from the enum
|
|
<PRE>
|
|
/* Pseudo-C */
|
|
typedef enum {
|
|
TypeKind_unconstrained = 0, /* anything not covered by other type kinds... */
|
|
TypeKind_boolean = 1, /* BOOLEAN */
|
|
TypeKind_s8 = 2, /* FIXED-POINT DENOM=1 MIN-NUM=-128 MAX-NUM=127 */
|
|
TypeKind_s16 = 3, /* FIXED-POINT DENOM=1 MIN-NUM=-32768 MAX-NUM=32767 */
|
|
TypeKind_s32 = 4, /* FIXED-POINT DENOM=1 MIN-NUM=-2147483648 MAX-NUM=2147483647 */
|
|
TypeKind_s64 = 5, /* FIXED-POINT DENOM=1 MIN-NUM=-9223372036854775808
|
|
MAX-NUM=9223372036854775807 */
|
|
TypeKind_u8 = 6, /* FIXED-POINT DENOM=1 MIN-NUM=0 MAX-NUM=255 */
|
|
TypeKind_u16 = 7, /* FIXED-POINT DENOM=1 MIN-NUM=0 MAX-NUM=65535 */
|
|
TypeKind_u32 = 8, /* FIXED-POINT DENOM=1 MIN-NUM=0 MAX-NUM=4294967296 */
|
|
TypeKind_u64 = 9, /* FIXED-POINT DENOM=1 MIN-NUM=0 MAX-NUM=18446744073709551616 */
|
|
TypeKind_ieee_float32 = 10, /* FLOATING-POINT SIGNIFICAND-SIZE=24 EXPONENT-BASE=2
|
|
MAXIMUM-EXPONENT-VALUE=127 MINIMUM-EXPONENT-VALUE=-126
|
|
HAS-NOT-A-NUMBER=TRUE HAS-INFINITY=TRUE
|
|
DENORMALIZED-VALUE-ALLOWED=TRUE HAS-SIGNED-ZERO=TRUE */
|
|
TypeKind_ieee_float64 = 11, /* FLOATING-POINT SIGNIFICAND-SIZE=53 EXPONENT-BASE=2
|
|
MAXIMUM-EXPONENT-VALUE=1023 MINIMUM-EXPONENT-VALUE=-1022,
|
|
HAS-NOT-A-NUMBER=TRUE HAS-INFINITY=TRUE
|
|
DENORMALIZED-VALUE-ALLOWED=TRUE HAS-SIGNED-ZERO=TRUE */
|
|
TypeKind_i_default_str = 12, /* STRING LANGUAGE="i-default" */
|
|
TypeKind_object = 13, /* local or remote object */
|
|
...
|
|
/* other types like Date, etc, should be added here... */
|
|
...
|
|
} PickleTypeKind;
|
|
</PRE>
|
|
<P>
|
|
If the value of <CODE>type_kind</CODE> is
|
|
<CODE>TypeKind_unconstrained</CODE>, the value of <CODE>type_kind_len</CODE>
|
|
is the length of a value of XDR type <CODE>fixed-length opaque data</CODE>,
|
|
containing the full string type ID of the type, which immediately follows
|
|
the header. Otherwise, no <CODE>opaque data</CODE> is marshalled.
|
|
<P>
|
|
For the purposes of marshalling, pickles have no default charset; this means
|
|
that strings marshalled into a pickle should always contain an explicit charset.
|
|
Pickles should be considered a single "message" for the purposes of marshalling
|
|
aliased reference types.
|
|
<P>
|
|
<H2>
|
|
7.10. Reference Types
|
|
</H2>
|
|
<P>
|
|
<H3>
|
|
7.10.1. Optional Types
|
|
</H3>
|
|
<P>
|
|
<A NAME="IDX72"></A>
|
|
<P>
|
|
Optional types are passed as XDR <CODE>optional-data</CODE>.
|
|
<P>
|
|
<H3>
|
|
7.10.2. Aliased Types
|
|
</H3>
|
|
<P>
|
|
<A NAME="IDX73"></A>
|
|
<P>
|
|
The scope of aliasing in this protocol is the message, as in Java RMI, rather
|
|
than the call, as in DCE RPC. That is, aliasing occurs only within the context
|
|
of a single invocation or result, rather than across a full invocation-result
|
|
pair. For the purposes of marshalling, a pickle scope should be considered
|
|
a single message scope.
|
|
<P>
|
|
Each unique value of an aliased type that is marshalled is assigned a 32-bit
|
|
unsigned integer value, unique in the scope of aliasing, called its
|
|
<DFN>aliased identifier</DFN>. This identifier is marshalled as an XDR
|
|
<CODE>unsigned integer</CODE>. If the aliased value has not previously been
|
|
sent in this scope, its value is then marshalled as a value of its base type
|
|
would be. Note that this means that the full value of every aliased type
|
|
is sent only once in a scope; subsequent occurrences send only the aliased
|
|
identifier.
|
|
<P>
|
|
[ XXX - how to handle overflow of aliased value cache? ]
|
|
<P>
|
|
<H2>
|
|
7.11. Object Types
|
|
</H2>
|
|
<P>
|
|
<A NAME="IDX74"></A>
|
|
<P>
|
|
An instance of an object type is passed as the state of the object type,
|
|
which also contains information about the actual type of the value. For remote
|
|
object types, this state is followed by the object identifier, and optionally
|
|
information about how the instance may be contacted.
|
|
<P>
|
|
<H3>
|
|
7.11.1. Parameter Type Versus Actual Type
|
|
</H3>
|
|
<P>
|
|
<A NAME="IDX75"></A>
|
|
<P>
|
|
When marshalling the state of an object, it's important to distinguish two
|
|
important types of the value: the <DFN>parameter type</DFN>, which is the
|
|
type that both sides of the session expect the value to have, and the
|
|
<DFN>actual type</DFN> of the value, which is the most-derived type of the
|
|
object, and may be a subtype of the parameter type. If the actual type is
|
|
different from the parameter type, extra information must be passed along
|
|
with the value to allow the receiver to properly distinguish the type and
|
|
its associated data. However, if the actual type is the same as the parameter
|
|
type, some of this information can be omitted.
|
|
<P>
|
|
<H3>
|
|
7.11.2. Passing the Actual Type ID
|
|
</H3>
|
|
<P>
|
|
We pass the state of the object type as the type ID of the most-derived-type
|
|
of the object, followed by the state attributes of each type of the object.
|
|
The type ID is passed as one of three values, depending on the following
|
|
conditions:<BR>
|
|
<OL>
|
|
<LI>
|
|
If the parameter type of the object is sealed, both sides already know the
|
|
most-derived-type ID of the instance, and know that the actual type must
|
|
be the same as the parameter type. In this case, the type ID is passed as
|
|
XDR <CODE>void</CODE>.
|
|
<LI>
|
|
If the actual type of the object is the same as the parameter type, this
|
|
is indicated by passing a zero-length value of XDR <CODE>variable-length
|
|
opaque data</CODE>.
|
|
<LI>
|
|
Otherwise, the type ID is passed as a value of XDR <CODE>variable-length
|
|
opaque data</CODE> containing the type ID.
|
|
</OL>
|
|
<P>
|
|
<H3>
|
|
7.11.3. Passing the State Attributes
|
|
</H3>
|
|
<P>
|
|
The state attributes are marshalled in one of two ways:<BR>
|
|
<OL>
|
|
<LI>
|
|
If the actual type of the instance is the same as the parameter type, the
|
|
state of each of the types of the object are passed by walking the supertype
|
|
inheritance tree of the instance in a depth-first order, passing the value
|
|
of each attribute of any particular state in the order in which they are
|
|
defined, as if each state formed an XDR <CODE>structure</CODE> with the
|
|
attributes as the components of the structure. The value of each attribute
|
|
is marshalled directly according to the type of the attribute.
|
|
<LI>
|
|
If the actual type of the instance is a subtype of the parameter type, the
|
|
receiver has to be able to handle state for types it has no knowledge of.
|
|
To allow for this, the state of each type is passed as an encapsulation.
|
|
That is, the state of the instance is passed as a sequence of XDR
|
|
<CODE>structure</CODE> values, each containing the state for one of the types
|
|
of the instance. Types of the instance which have no associated state do
|
|
not appear in this sequence. An XDR expression of the sequence would be the
|
|
following: <A NAME="IDX77"></A> <A NAME="IDX76"></A>
|
|
<PRE>
|
|
/* XDR */
|
|
struct {
|
|
opaque type_id<0xFFFF>;
|
|
opaque state<>;
|
|
} TypeState;
|
|
typedef TypeState StateSequence<>;
|
|
</PRE>
|
|
<P>
|
|
The <I>type_id</I> field contains the type ID for that type of the the object
|
|
value. The variable-length opaque data field <I>state</I> contains the values
|
|
of the attributes of the state marshalled as an XDR <CODE>structure</CODE>,
|
|
where the components of the structure are the attributes of the state.
|
|
</OL>
|
|
<P>
|
|
<H3>
|
|
7.11.4. Passing the Object ID and Contact Info
|
|
</H3>
|
|
<P>
|
|
<A NAME="IDX78"></A> <A NAME="IDX79"></A> <A NAME="IDX80"></A>
|
|
<A NAME="IDX81"></A> <A NAME="IDX82"></A>
|
|
<P>
|
|
In the case of a remote object type, the server ID, instance handle and contact
|
|
info for the value are passed as a value of the following XDR structure type
|
|
<CODE>RemoteObjectInfo</CODE>:
|
|
<PRE>
|
|
/* XDR */
|
|
typedef string ContactInfo<0xFFFF>;
|
|
struct {
|
|
opaque server_id<>;
|
|
opaque instance_handle<>;
|
|
ContactInfo cinfos<>;
|
|
} RemoteObjectInfo;
|
|
</PRE>
|
|
<P>
|
|
where <I>server_id</I> is a identifier for the server which supports the
|
|
desired object, and <I>instance_handle</I> is a server-relative name for
|
|
the object. The <I>cinfos</I> field contains zero or more pieces of information
|
|
about the way in which the object needs to be contacted, including information
|
|
such as whether various transport layers are involved.
|
|
<P>
|
|
<A NAME="IDX83"></A>
|
|
<H1>
|
|
8. System Exceptions
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX84"></A>
|
|
<P>
|
|
<H2>
|
|
8.1. <CODE>UnknownProblem</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 0<BR>
|
|
ISL Values: None
|
|
<P>
|
|
An unknown problem occurred. <A NAME="IDX85"></A>
|
|
<P>
|
|
<H2>
|
|
8.2. <CODE>ImplementationLimit</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 1<BR>
|
|
ISL Values: None
|
|
<P>
|
|
The request could not be properly addressed because of some implementation
|
|
resource limit on the callee side. <A NAME="IDX86"></A>
|
|
<H2>
|
|
8.3. <CODE>SwitchConnectionCinfo</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 2<BR>
|
|
ISL Values: <VAR>NEW-CINFO</VAR> : <CODE>HTTP-ng-w3ng.CinfoString</CODE>
|
|
<P>
|
|
This exception requests the caller to upgrade the connection protocol and
|
|
transport information to the cinfo specified as the argument, and re-try
|
|
the call. This is the equivalent of the <CODE>UPGRADE</CODE> message in HTTP
|
|
1.1, and the <CODE>RELOCATE_REPLY</CODE> message in CORBA GIOP.
|
|
<A NAME="IDX87"></A>
|
|
<H2>
|
|
8.4. <CODE>Marshal</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 3<BR>
|
|
ISL Values: None
|
|
<P>
|
|
A marshalling problem was encountered. <A NAME="IDX88"></A>
|
|
<H2>
|
|
8.5. <CODE>NoSuchObjectType</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 4<BR>
|
|
ISL Values: None
|
|
<P>
|
|
The object type of the operation was unknown at the server.
|
|
<A NAME="IDX89"></A>
|
|
<H2>
|
|
8.6. <CODE>NoSuchMethod</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 5<BR>
|
|
ISL Values: None
|
|
<P>
|
|
The object type of the operation was known at the server, but did not contain
|
|
the indicated method. <A NAME="IDX90"></A>
|
|
<H2>
|
|
8.7. <CODE>NoSuchObject</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 6<BR>
|
|
ISL Values: None
|
|
<P>
|
|
The specified discriminant object was not available at the server.
|
|
<A NAME="IDX91"></A>
|
|
<H2>
|
|
8.8. <CODE>InvalidType</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 7<BR>
|
|
ISL Values: None
|
|
<P>
|
|
The object specified by the discriminant did not participate in the type
|
|
specified in the operation. <A NAME="IDX92"></A>
|
|
<H2>
|
|
8.9. <CODE>Rejected</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 8<BR>
|
|
ISL Values: <VAR>REASON</VAR> : <CODE>OPTIONAL SimpleString</CODE>
|
|
<P>
|
|
The server refused to process the request. It may return a string giving
|
|
a reason for the rejection.
|
|
<P>
|
|
<H2>
|
|
8.10. <CODE>OperationOrDiscriminantCacheOverflow</CODE>
|
|
</H2>
|
|
<P>
|
|
Exception Code: 9<BR>
|
|
ISL Values: None
|
|
<P>
|
|
The request caused the receiver's cache of operations or discriminants to
|
|
overflow. The sender may retry the request with uncached operation and
|
|
discriminant values; subsequent requests should not cache any additional
|
|
operation or discriminant values, but may continue to use previously successfully
|
|
cached values.
|
|
<P>
|
|
<H1>
|
|
9. Discussion
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX93"></A>
|
|
<P>
|
|
<H2>
|
|
9.1. Serial Numbers
|
|
</H2>
|
|
<P>
|
|
Does this protocol need to assign serial numbers to requests and replies?
|
|
We do so in order to be able to cancel operations by serial number, and to
|
|
be able to return reply messages out of order. The first problem, that of
|
|
cancelling operations, could be dealt with by keeping track of serial numbers
|
|
implicitly, and using an explicit serial number only in the
|
|
<CODE>CancelRequest</CODE> message. Doing this would imply that the replies
|
|
would have to be returned in the order in which the requests were passed,
|
|
but would allow us to have 6 byte request messages (4 bytes if we count the
|
|
discriminant as part of the arguments, instead of part of the header), and
|
|
4 byte reply messages. Thus the only real purpose for serial numbers is to
|
|
allow replies to be returned out of order (and possibly to make debugging
|
|
the protocol easier). There are other deeper unanswered questions here about
|
|
the serialization semantics of the protocol. For instance, should the callee
|
|
wait until dispatching a reply to one request until beginning to process
|
|
the next one?
|
|
<P>
|
|
The current answer to these questions is that it is highly useful to allow
|
|
a threaded callee to process multiple requests in parallel, and to allow
|
|
it to return requests out of order. Thus serial numbers are useful. We assume
|
|
that higher-level protocols desiring serialization will provide a serialization
|
|
context as part of the context of the call, and that serialization will be
|
|
handled at either a higher or lower level.
|
|
<P>
|
|
<A NAME="IDX94"></A>
|
|
<H2>
|
|
9.2. Memoizing of PICKLE and Object Types?
|
|
</H2>
|
|
<P>
|
|
A great deal of the traffic over this protocol may consist of values of type
|
|
PICKLE (the equivalent of object-by-value, or of HTTP's MIME-encapsulated
|
|
body type) or of some object type. It is tempting to introduce a form of
|
|
memoizing for these value types, similar to that used for request discriminants.
|
|
There are two reasons not to do so:
|
|
<OL>
|
|
<LI>
|
|
XDR provides no explicit support for memoizing, which means that we would
|
|
have to provide a marshalling format for these types which has no clean layering
|
|
onto XDR. For instance, it might be possible to pass an object value as an
|
|
XDR 32-bit unsigned integer with the following (private) pseudo-C structure
|
|
<PRE>
|
|
struct {
|
|
boolean use_cached_value : 1;
|
|
boolean cache_this_value : 1;
|
|
union {
|
|
unsigned int url_len : 30;
|
|
unsigned int cache_key : 30;
|
|
} v;
|
|
};
|
|
</PRE>
|
|
<P>
|
|
either by itself (if <CODE>use_cached_value</CODE> is set), or followed by
|
|
an XDR fixed length opaque value containing the URL for the object (if
|
|
<CODE>use_cached_value</CODE> is not set). This type of variable structure
|
|
has no equivalent in XDR. On the other hand, it could well be argued that
|
|
since we are marshalling an object type, something not explicitly covered
|
|
by XDR, that we are simply providing an extension to XDR, in the spirit of
|
|
the marshalling. We could even use a simpler construct, such as XDR union.
|
|
<LI>
|
|
A more powerful argument is that allowing arbitrary memoizing of large items
|
|
can let the caller place almost arbitrary loads on the storage requirements
|
|
of the callee. It could be argued that the callee can reset the connection
|
|
at any time if the load becomes too onerous via
|
|
<CODE>TerminateConnection</CODE>.
|
|
</OL>
|
|
<P>
|
|
Neither of these arguments seems overwhelmingly powerful.
|
|
<P>
|
|
<H2>
|
|
9.3. URL Forms
|
|
</H2>
|
|
<P>
|
|
Open issues:
|
|
<UL>
|
|
<LI>
|
|
We need to specify a default object type (and default <VAR>CINFO</VAR>?).
|
|
<LI>
|
|
The exact format of <VAR>TYPEID</VAR> values and <VAR>CINFO</VAR> stacks
|
|
must also be specified.
|
|
<LI>
|
|
The form of <VAR>SERVER-ID</VAR> should also be defined to allow slash characters
|
|
internally.
|
|
<LI>
|
|
Should <VAR>SERVER-ID</VAR> be stylized in a way which makes it easy to use
|
|
with DNS?
|
|
<LI>
|
|
How should HTTP URLs be integrated into this, if at all?
|
|
<LI>
|
|
Should we have multiple URL forms, with some information about the cinfo
|
|
being integrated into some of the forms? For example, Henrik has suggested
|
|
that a URL of the form
|
|
<CODE>http-ng://foo.bar.com/<VAR>object-id</VAR></CODE> might be used to
|
|
indicate that object <VAR>object-id</VAR> is available at
|
|
<CODE>foo.bar.com</CODE>, and that the client should use some protocol
|
|
negotiation protocol to work out the exact shape of the cinfo.
|
|
</UL>
|
|
<P>
|
|
<A NAME="IDX95"></A>
|
|
<P>
|
|
Proposed: URLs for HTTP-ng objects will be of the form
|
|
<PRE>
|
|
w3ng:<VAR>SERVER-ID</VAR>/<VAR>INSTANCE-HANDLE</VAR>[;type=<VAR>TYPE</VAR>][;cinfo=<VAR>CINFO</VAR>]
|
|
</PRE>
|
|
<P>
|
|
where <VAR>SERVER-ID</VAR> is a identifier for the server which supports
|
|
the desired object; <VAR>INSTANCE-HANDLE</VAR> is a server-relative name
|
|
for the object; <VAR>TYPE</VAR> is the type ID for the most derived type
|
|
of the object; and <VAR>CINFO</VAR> is information about the way in which
|
|
the object needs to be contacted, including information such as whether various
|
|
transport layers are involved. This form has the virtue of becoming a URN
|
|
if the optional <VAR>CINFO</VAR> and <VAR>TYPE</VAR> fields are omitted.
|
|
<P>
|
|
<H2>
|
|
9.4. Current syntax of Cinfo strings
|
|
</H2>
|
|
<P>
|
|
The syntax of cinfo currently follows the ILU definition. Each cinfo string
|
|
has the form described below (where brackets indicate optionality, an
|
|
<ALPHANUMERIC-ID> is an identifier composed of ASCII lowercase alphabetic
|
|
and numeric characters, beginning with a lowercase alphabetic character,
|
|
and a <NON-UNDERSCORE-STRING> is any string of ASCII characters not
|
|
containing the underscore character '_'):
|
|
<P>
|
|
<PRE>
|
|
<cinfo> := <pinfo> '@' <tinfo-stack>
|
|
|
|
<pinfo> := <scheme> [ '_' <parms> ]
|
|
|
|
<scheme> := <ALPHANUMERIC-ID>
|
|
|
|
<parms> := <parm> [ '_' <parms> ]
|
|
|
|
<parm> := <NON-UNDERSCORE-STRING>
|
|
|
|
<tinfo-stack> := <tinfo> [ '=' <tinfo-stack> ]
|
|
|
|
<tinfo> := <scheme> [ '_' <parms> ]
|
|
</PRE>
|
|
<P>
|
|
<H3>
|
|
9.4.1. Syntax of <CODE>w3ng</CODE> Pinfo
|
|
</H3>
|
|
<P>
|
|
The current syntax of the pinfo string for the ILU implementation of the
|
|
<CODE>w3ng</CODE> wire protocol is
|
|
<P>
|
|
<PRE>
|
|
<scheme> := 'w3ng'
|
|
|
|
<parms> := <major-version> [ '.' <minor-version> ]
|
|
</PRE>
|
|
<P>
|
|
where <CODE><major-version></CODE> and
|
|
<CODE><minor-version></CODE> are numbers between 0 and 15. If the
|
|
<CODE><minor-version></CODE> is not specified, it defaults to 0.
|
|
<P>
|
|
<H3>
|
|
9.4.2. Syntax of <CODE>w3mux</CODE> Tinfo
|
|
</H3>
|
|
<P>
|
|
The current syntax of the tinfo string for the ILU implementation of the
|
|
<CODE>w3mux</CODE> transport layer is
|
|
<P>
|
|
<PRE>
|
|
<scheme> := 'w3mux'
|
|
|
|
<parms> := <channel> '_' <endpoint>
|
|
</PRE>
|
|
<P>
|
|
where <CODE><channel></CODE> is a protocol ID number [MUX], and
|
|
<CODE><endpoint></CODE> is a UUID string for an endpoint. The size
|
|
of the <CODE><endpoint></CODE> string must be less than 1000 bytes.
|
|
<P>
|
|
<H3>
|
|
9.4.3. Syntax of <CODE>tcp</CODE> Tinfo
|
|
</H3>
|
|
<P>
|
|
The current syntax of the tinfo string for the ILU implementation of the
|
|
<CODE>tcp</CODE> transport layer is
|
|
<P>
|
|
<PRE>
|
|
<scheme> := 'tcp'
|
|
|
|
<parms> := <host> '_' <port>
|
|
</PRE>
|
|
<P>
|
|
where <CODE><host></CODE> is string of less than 1000 bytes indicating
|
|
the IP address or hostname of the remote machine, and
|
|
<CODE><port></CODE> is the TCP port on which the host is listening.
|
|
<P>
|
|
<H3>
|
|
9.4.4. Syntax of <CODE>sunrpcrm</CODE> Tinfo
|
|
</H3>
|
|
<P>
|
|
The current syntax of the tinfo string for the ILU implementation of the
|
|
<CODE>sunrpcrm</CODE> transport layer is
|
|
<P>
|
|
<PRE>
|
|
<scheme> := 'sunrpcrm'
|
|
</PRE>
|
|
<P>
|
|
No parameters are defined. This layer implements the ONC RPC record-marking
|
|
scheme on top of a reliable byte stream, as defined in section 10 of the
|
|
ONC RPC RFC [ONC RPC].
|
|
<P>
|
|
<H1>
|
|
10. References
|
|
</H1>
|
|
<P>
|
|
RFC 2278:
|
|
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2278.txt">http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2278.txt</A>
|
|
<P>
|
|
XDR [RFC 1832]:
|
|
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1832.txt">http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1832.txt</A>
|
|
<P>
|
|
ONC RPC [RFC 1831]:
|
|
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1831.txt">http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1831.txt</A>
|
|
<P>
|
|
ISL:
|
|
<A HREF="ftp://ftp.parc.xerox.com/pub/ilu/2.0a12/manual-html/manual_2.html">ftp://ftp.parc.xerox.com/pub/ilu/2.0a12/manual-html/manual_2.html</A>
|
|
<P>
|
|
WD-HTTP-NG-arch-model (work in progress):
|
|
<A HREF="http://www.w3.org/TR/1998/WD-HTTP-NG-architecture">http://www.w3.org/TR/1998/WD-HTTP-NG-architecture</A>
|
|
<P>
|
|
MUX (work in progress):
|
|
<A HREF="http://www.w3.org/TR/1998/WD-mux-971203">http://www.w3.org/TR/1998/WD-mux</A>
|
|
<P>
|
|
ILU:
|
|
<A HREF="ftp://ftp.parc.xerox.com/pub/ilu/2.0a12/manual-html/manual_2.html">ftp://ftp.parc.xerox.com/pub/ilu/2.0a12/manual-html/manual_2.html</A>
|
|
<H1>
|
|
11. Address of Author
|
|
</H1>
|
|
<P>
|
|
<A NAME="IDX96"></A>
|
|
<P>
|
|
Bill Janssen<BR>
|
|
Xerox Palo Alto Research Center<BR>
|
|
3333 Coyote Hill Rd<BR>
|
|
Palo Alto, CA 94304<BR>
|
|
<P>
|
|
Phone: (650) 812-4763<BR>
|
|
FAX: (650) 812-4777<BR>
|
|
Email: janssen@parc.xerox.com<BR>
|
|
HTTP: http://www.parc.xerox.com/istl/members/janssen/<BR>
|
|
<H1>
|
|
Index
|
|
</H1>
|
|
<UL>
|
|
<LI>
|
|
<H2>
|
|
a
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX73">aliased types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX17">alignment</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX68">array of byte, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX67">array types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX96">author</A>
|
|
<H2>
|
|
b
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX15">big-endian</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX56"><CODE>BOOLEAN</CODE></A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX21"><CODE>Boolean</CODE> (pseudo-C enum
|
|
type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX57">boolean type, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX14">byte order</A>
|
|
<H2>
|
|
c
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX80">cinfo, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX3">connection, definition of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX81">contact info, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX22"><CODE>ControlMsgType</CODE> (pseudo-C
|
|
enum type)</A>
|
|
<H2>
|
|
d
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX52"><CODE>DefaultCharsetMsgHeader</CODE> (pseudo-C
|
|
struct type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX42">discriminant object ID memoizing</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX40">discriminant, identification of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX24"><CODE>DiscriminantID</CODE> (pseudo-C
|
|
struct type)</A>
|
|
<H2>
|
|
e
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX58">enumeration types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX33">extension headers</A>
|
|
<H2>
|
|
f
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX60">fixed-point types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX55">flagged variable-length opaque data (XDR
|
|
type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX62"><CODE>FloatingPointValueType</CODE> (XDR
|
|
type)</A>
|
|
<H2>
|
|
g
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX61"><CODE>GeneralFloatingPointValue</CODE>
|
|
(XDR type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX50">graceful connection shutdown</A>
|
|
<H2>
|
|
h
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX35"><CODE>HTTP-ng-w3ng.ExtensionHeader</CODE>
|
|
(ISL type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX34"><CODE>HTTP-ng-w3ng.ExtensionHeaderList</CODE>
|
|
(ISL type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX36"><CODE>HTTP-ng-w3ng.SimpleString</CODE>
|
|
(ISL type)</A>
|
|
<H2>
|
|
i
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX85"><CODE>ImplementationLimit</CODE> (system
|
|
exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX46"><CODE>InitializeConnection</CODE>
|
|
message</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX47"><CODE>InitializeConnectionMsgHeader</CODE>
|
|
(pseudo-C struct type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX8">instance handle</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX78">instance handle, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX59">integer types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX5">interface</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX91"><CODE>InvalidType</CODE> (system
|
|
exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX53">ISL->XDR mapping</A>
|
|
<H2>
|
|
m
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX87"><CODE>Marshal</CODE> (system exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX54">marshalling of data</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX43">memoizing</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX94">memoizing of pickle and object types</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX13">message-oriented transport</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX29">messages, description of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX4">model of operation</A>
|
|
<H2>
|
|
n
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX63"><CODE>NormalFloatingPointValue</CODE>
|
|
(XDR type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX89"><CODE>NoSuchMethod</CODE> (system
|
|
exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX90"><CODE>NoSuchObject</CODE> (system
|
|
exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX88"><CODE>NoSuchObjectType</CODE> (system
|
|
exception)</A>
|
|
<H2>
|
|
o
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX7">object ID</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX75">object state, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX74">object types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX41">operation ID memoizing</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX39">operation, identification of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX25"><CODE>OperationID</CODE> (pseudo-C struct
|
|
type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX72">optional types, marshalling of</A>
|
|
<H2>
|
|
p
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX16">padding</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX71">pickle types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX27"><CODE>ProtocolVersion</CODE> (pseudo-C
|
|
struct type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX2">pseudo-C syntax, definition of</A>
|
|
<H2>
|
|
r
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX69">record types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX92"><CODE>Rejected</CODE> (system exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX10">reliable sequenced message transport</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX79">remote object types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX44"><CODE>Reply</CODE> message</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX45"><CODE>ReplyMsgHeader</CODE> (pseudo-C
|
|
struct type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX23"><CODE>ReplyStatus</CODE> (pseudo-C enum
|
|
type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX37"><CODE>Request</CODE> message</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX38"><CODE>RequestMsgHeader</CODE> (pseudo-C
|
|
struct type)</A>
|
|
<H2>
|
|
s
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX19">security</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX66">sequence of byte, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX65">sequence types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX12">sequenced transport</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX93">serial numbers, discussion of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX9">serial numbers, range of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX6">server ID</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX20">session context</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX76"><CODE>StateSequence</CODE> (XDR type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX64">string types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX30"><CODE>Success</CODE> subtype of Reply</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX86"><CODE>SwitchConnectionCinfo</CODE> (system
|
|
exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX1">syntax used</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX83">system exceptions</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX32"><CODE>SystemException</CODE> subtype of
|
|
Reply</A>
|
|
<H2>
|
|
t
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX51"><CODE>TerminateConnection</CODE> message</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX49"><CODE>TerminateConnectionMsgHeader</CODE>
|
|
(pseudo-C struct type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX26"><CODE>TerminationCause</CODE> (pseudo-C
|
|
enum type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX11">transport requirements</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX77"><CODE>TypeState</CODE> (XDR type)</A>
|
|
<H2>
|
|
u
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX70">union types, marshalling of</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX84"><CODE>UnknownProblem</CODE> (system
|
|
exception)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX28"><CODE>Unused</CODE> (pseudo-C alias
|
|
type)</A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX31"><CODE>UserException</CODE> subtype of
|
|
Reply</A>
|
|
<H2>
|
|
w
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX95"><CODE>w3ng</CODE> URL form</A>
|
|
<H2>
|
|
x
|
|
</H2>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX82">XDR type
|
|
<CODE>RemoteObjectInfo</CODE></A>
|
|
<LI>
|
|
<A HREF="wire-encoding.html#IDX18">XDR, Internet RFC 1832, use of</A>
|
|
</UL>
|
|
</BODY></HTML>
|