Page: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
---|---|---|---|---|---|---|---|---|---|
10 | 11 | 12 | 13 | 14 | 15 | 16 |
Version 1.0
X Consortium Standard
X Version 11, Release 6
Ralph Mor
X Consortium
Copyright © 1993, 1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Soft ware, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHITER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Except as contained in this notice, the name of the X Consortium shall not be used in
advertising or otherwise to promote the sale, use or other dealings in this Software
without prior written authorization from the X Consortium.
X Window System is a trademark of X Consortium, Inc.
Thanks to Bob Scheifler for his thoughtful input on the design of the ICE library.
Thanks also to Jordan Brown, Larry Cable, Donna Converse, Clive Feather, Stephen Gildea,
Vania Joloboff, Kaleb Keithley, Stuart Marks, Hiro Miyamoto, Ralph Swick, Jirn VanGilder,
and Mike Wexler.
There are numerous possible "inter-client" protocols, with many similarities
and common needs - authentication, version negotiation, byte order negotiation, etc. The
ICE protocol is intended to provide a framework for building such protocols, allowing them
to make use of common negotiation mechanisms and to be multiplexed over a single transport
connection.
A client that wishes to utilize ICE must first register the protocols it understands with the ICE library. Each protocol is dynamically assigned a major opcode ranging from 1-255 (two clients can use different major opcodes for the same protocol). The next step for the client is to either open a connection with another client, or to wait for connections made by other clients. Authentication may be required. A client can both initiate connections with other clients and be waiting for clients to connect to itself (a nested session manager is an example). Once an ICE connection is established between the two clients, one of the clients needs to initiate a Protocol Setup in order to "activate" a given protocol. Once the other client accepts the Protocol Setup (once again, authentication may be required), the two clients are ready to start passing messages specific to that protocol to each other. Multiple protocols may be active on a single ICE connection. Clients are responsible for notifying the ICE library when a protocol is no longer active on an ICE connection, although ICE does not define how each sub-protocol triggers a protocol shutdown.
The ICE library utilizes callbacks to process incoming messages. Using callbacks allows
Protocol Setups and authentication to happen "behind the scenes." An
additional benefit is that messages never need to be buffered up by the library when the
client "blocks" waiting for a particular message.
This document is intended primarily for implementors of protocol libraries layered on
top of ICE. Typically, applications that wish to utilize ICE will make calls into
individual protocol libraries rather than directly make calls into the ICE library.
However, some applications will have to make some initial calls into the ICE library in
order to accept ICE connections (for example, a session manager accepting connections from
clients). But in general, protocol libraries should be designed to hide the inner details
of ICE from applications.
The header file <X11/ICE/ICE/ICElib.h>defines all of the ICE lib data structures and function prototypes. ICElib.hincludes the header file <X11/ICE/ICE.h>which defines all of the ICElib constants. Protocol libraries that need to read and write messages should include the header file <X11/ICE/ICEmsg.h>.
Applications should link against ICElib using -lICE.
The following name prefixes are used in the library to distinguish between a client
that initiates a Protocol Setup and a client which responds with a Protocol
Reply:
IcePo - Ice Protocol Originator
IcePa - Ice Protocol Acceptor
In order for two clients to exchange messages for a given protocol, each side must register the protocol with the ICE library. The purpose of registration is for each side to obtain a major opcode for the protocol, and to provide callbacks for processing messages and handling authentication. There are two separate registration functions - one to handle the side that does a Protocol Setup, and one to handle the side that responds with a Protocol Reply.
It is recommended that protocol registration occur before the two clients establish an ICE connection. If protocol registration occurs after an ICE connection is created, there can be a brief interval of time in which a Protocol Setup is received, but the protocol is not registered. If it is not possible to register a protocol before the creation of an ICE commotion, proper precautions should be taken to avoid the above race condition.
The IceRegisterForProtocolSetup function
should be called for the client that initiate a Protocol Setup.
protocol_narne | A string specifying the name of the protocol to register. |
vendor | A vendor string with semantics specified by the protocol. |
release | A release string with semantics specified by the protocol. |
version_count | The number of different versions of the protocol supported. |
version_recs | List of versions and associated callbacks. |
auth_count | The number of authentication methods supported. |
auth_narnes | The list of authentication methods supported. |
auth_procs | The list of authentication callbacks, one for each authentication method. |
io_error_proc | IO Error handler. |
IceRegisterForProtocolSetup returns the major opcode reserved, or -1 if an error occurred. In order to actually activate the protocol, the IceProtocolSetup function needs to be called with this major opcode. Once the protocol is activated, all messages for the protocol should be sent using this major opcode.
A protocol library may support multiple versions of the same protocol. version recs.
specifies a list of supported versions of the protocol, prioritized in decreasing
order of preference. Each version record consists of a major and minor version of the
protocol, as well as a callback to be used for processing incoming messages.
typedef struct { int major_version; int minor_version; IcePoProcessMsgProc process_msg_proc; } IcePoVersionRec;
The IcePoProcessMsgProc callback is responsible for processing the set of messages that can be received
by the client that initiated the Protocol Setup. The details of how this callback works is described in the section titled Callbacks for Processing Messages.
Authentication may be required before the protocol can become active. The protocol library must register the authentication methods that it supports with the ICE library. auth_names and auth_procs are a list of authentication names and callbacks, prioritized in decreasing order of preference. The details of how the IcePoAuthProc callback works is described in the section titled Authentication Methods.
The IceIOErrorProc callback is invoked if the ICE connection unexpectedly
breaks.Pass NULL for io_error_proc if not interested in being notified. See Section 11.12, Error Handling, for more details
on this callback.
The IceRegisterForProtocolReply
function should be called for the client that responds to a Protocol Setup with a Protocol
Reply.
protocol_narne | A string specifying the name of the protocol to register. |
vendor | A vendor string with semantics specified by the protocol. |
release | A release string with semantics specified by the protocol. |
version_count | The number of different versions of the protocol supported. |
version_recs | List of versions and associated callbacks. |
auth_count | The number of authentication methods supported. |
auth_narnes | The list of authentication methods supported. |
auth_procs | The list of authentication callbacks, one for each authentication method. |
host_based_auth_proc | Host based authentication callback. |
protocol_setup_proc | A callback to be invoked when authentication has succeeded for a Protocol Setup, before the Protocol Reply is sent. |
protocol activate_proc | A callback to be invoked after the Protocol Reply is sent. |
io_error_proc | IO Error handler. |
IceRegisterForProtocolReply returns the major opcode reserved, or -1 if an error occurred. The major opcode should be used in all subsequent messages sent for this protocol.
A protocol library may support multiple versions of the same protocol. version recs specifies a list of supported versions of the protocol, prioritized in decreasing order of preference. Each version record consists
of a major and minor version of the protocol, as well as a callback to be used for
processing incoming messages.
typedef struct { int major_version; int minor_version; IcePaProcessMsgProc process_msg_proc; } IcePaVersionRec;
The IcePaProcessMsgProc callback is responsible for processing the set of messages that can be received by the client that accepted the Protocol Setup.The details of how this callback works is described in the section titled Callbacks for Processing Messages.
Authentication may be required before the protocol can become active. The protocol library must register the authentication methods that it supports with the ICE library. auth_names and auth_procs are a list of authentication names and callbacks, prioritized in decreasing order of preference. The details of how the IcePoAuthProc callback works is described in the section titled Authentication Methods.
If authentication fails and the client attempting to initiate the Protocol Setup has
not required authentication, the IceHostBasedAuthProc callback is invoked with the
host name of the originating client. If the callback returns True, the Protocol
Setup will succeed, even though the original authentication failed. Note that
authentication can effectively be disabled by registering an IceHostBasedAuthProc which
always returns True. If no host based authentication is allowed, pass NULL
for host_based_auth_proc.
typedef Bool (*IceHostBasedAuthProc) ();
host_narne | The host name of the client that sent the Protocol Setup. |
host_name | is a string of the form "protocol/hostname", where protocol is one of { tcp, decent, local } . |
Since Protocol Setups and authentication happen "behind the scenes" via callbacks, the protocol library needs some way of being notified when the Protocol Setup has completed. This occurs in two phases. In the first phase, the IceProtocolSetupProc callback is invoked after authentication has successfully completed, before the ICE library sends a Protocol Reply. Any resources required for this protocol should be allocated at this time. If the IceProtocolSetupProc returns a successful status, the ICE library will send the Protocol Reply and then invoke the IceProtocolActivateProc callback. Otherwise, an error will be sent to the other client in response to the Protocol Setup.
The IceProtocolActivateProc is an optional callback, and should be registered
only if the protocol library intends to generate a message immediately following the Protocol
Reply. Pass NULL for protocol_activate proc if not interested in this
callback.
typedef Status (*IceProtocolSetupProc) ();
ice_conn | The ICE connection object. |
major_version | The major version of the protocol. |
minor_version | The minor version of the protocol. |
vendor | The vendor string registered by the protocol originator. |
release | The release string registered by the protocol originator. |
client data_ret | Client data to be set by callback. |
failure reason_ret | Failure reason returned. |
The pointer stored in the client_data_ret argument will be passed to the IcePaProcessMsgProc callback whenever a message has arrived for this protocol on the ICE connection.
The vendor and release strings should be freed with free() when they are no longer needed.
If a failure occurs, the IceProtocolSetupProc should return a zero status, as
well as allocate and return a failure reason string in failure reason_ret. The ICE
library will be responsible for freeing this memory.
The IceProtocolActivateProc discussed above is defined as follows:
typedef void (*IceProtocolActivateProc) ();
ice_conn | The ICE connection object. |
client data | The client data set in the IceProtocolSetupProc callback. |
The IcelOErrorProc callback is invoked if the ICE connection unexpectedly
breaks. Pass NULL for io error proc if not interested in being notified. See Section 11.12, Error Handling, for more details
on this callback.
When an application detects that there is a new data to read on an ICE connection (via select), it calls the IceProcessMessages function (discussed in the section titled Processing Messages). When IceProcessMessages reads an ICE message header with a major opcode other than zero (reserved for the ICE protocol), it needs to call a function which will read the rest of the message, unpack it, and process it accordingly.
If the message arrives at the client which initiated the Protocol Setup, the IcePoProcessMsgProc callback is invoked.
typed void (*IcePoProcessMsgProc) ();
ice_conn | The ICE connection object. |
client_data | Client data associated with this protocol on the ICE connection. |
opcode | The minor opcode of the message. |
length | The length (in 8 byte units) of the message beyond the ICE header. |
swap | A flag which indicates if byte swapping is necessary. |
reply_wait | Indicates if the invoking client is waiting for a reply. |
reply_ready_ret | If set to True, a reply is ready. |
If the message arrives at the client which accepted the Protocol Setup, the IcePaProcessMsgProc
callback is invoked.
typedef void (*IcePaProcessMsgProc)();
ice_conn | The ICE connection object. |
client_data | Client data associated with this protocol on the ICE connection. |
opcode | The minor opcode of the message. |
length | The length (in 8 byte units) of the message beyond the ICE header. |
swap | A flag which indicates if byte swapping is necessary. |
In order to read the message, both of the above callbacks should use the macros defined in the section of this document titled Reading ICE Messages. Note that byte swapping may be necessary. As a convenience, the length field in the ICE header will be swapped by ICElib if necessary.
In both of the above callbacks, client_data is a pointer to client data that was registered at Protocol Setup time. In the case of IcePoProcessMsgProc, the client data was set in the call to IceProtocolSetup. In the case of IcePaProcessMsgProc,the client data was set in the IceProtocolSetupProc callback.
The IcePoProcessMsgProc callback needs to check the reply_wait argument. If reply_wait is NULL,the ICE library expects the function to pass the message to the client via a callback. For example, if this is a Session Management Save Yourself message, this function should notify the client of the Save Yourself via a callback. The details of how such a callback would be defined is implementation dependent.
However, if reply_wait is not NULL, then the client is waiting for a reply or an error for a message it previously sent. reply_wait is of type IceReplyWaitInfo.
typedef struct { unsigned long sequence_of_request; int major_opcode_of_request; int minor_opcode_of_request; IcePointer reply; } IceReplyWaitInfo;
IceReplyWaitlnfo contains the major/minor opcodes and sequence number of the message for which a reply is being awaited. it also contains a pointer to the reply message to be filled in (the protocol library should cast this IcePOINTER to the appropriate reply type). In most cases, the reply will have some fixed-size part, and the client waiting for the reply will have provided a pointer to a structure to hold this fixed-size data. If there is variable-length data, it would be expected that the IcePoProcessMsgProc callback will have to allocate additional memory and store pointer(s) to that memory in the fixed-size structure. If the entire data is variable length (e.g., a single variable-length string), then the client waiting for the reply would probably just pass a pointer to fixed-size space to hold a pointer, and the IcePoProcessMsgProc callback would allocate the storage and store the pointer. It is the responsibility of the client receiving the reply to free any memory allocated on its behalf.
If reply_wait is not NULL and IcePoProcessMsgProc has a reply or error to return in response to this reply_wait (i.e. no callback was generated), then the reply_ready_ret argument should be set to True. Note that an error should only be returned if it corresponds to the reply being waited for. Otherwise, the IcePoProcessMsgProc should either handle the error internally, or invoke an error handler for its library.
If reply_wait is NULL, then care must be taken not to store any value in reply_ready_ret since this pointer may also be NULL.
The IcePaProcessMsgProc callback, on the other hand, should always pass the message to the client via a callback. For example, if this is a Session Management Interact Request message, this function should notify the client of the Interact Request via a callback.
The reason the IcePaProcessMsgProc callback does not have a reply_wait like IcePoProcessMsgProc does, is because a process that is acting as a "server" should never block for a reply (infinite blocking can occur if the connecting client does not act properly, denying access to other clients).
As discussed earlier, a protocol library must register the authentication methods that it soupiness with the ICE library. For each authentication method, there are two callbacks that may be registered - one to handle the side that initiates a Protocol Setup, and one to handle the side that accepts or rejects this request.
IcePoAuthProc is the callback invoked for the client that initiated the Protocol Setup. This callback must be able to respond to the initial Authentication Required message or subsequent Authentication Next Phase messages sent by the other client.
typedef IcePoAuthStatus (*IcePoAuthProc)();
ice_conn | The ICE connection object. |
auth_state_ptr | A pointer to state for use by the authentication callback procedure. |
clean_up | If True, authentication is over, and the function should clean up any state it was maintaining. The last 6 arguments should be ignored. |
swap | If True, the auth_data may have to be byte swapped (depending on its contents). |
auth_datalen | The length (in bytes) of the authenticator data. |
auth_data | The data from the authenticator. |
reply_datalen_ret | The length (in bytes) of the reply data returned. |
reply_data_ret | The reply data returned. |
error_string_ret | If the authentication procedure encounters an error during authentication, it should allocate and return an error string. |
Authentication may require several phases, depending on the authentication method. As a result, the IcePoAuthProc may be called more than once when authenticating a client, and some state will have to be maintained between each invocation. At the start of each Protocol Setup, *auth_state_ptr is NULL, and the function should initialize its state and set this pointer. In subsequent invocations of the callback, the pointer should be used to get at any state previously stored by the callback.
If needed, the network ID of the client accepting the Protocol Setup can be obtained by calling the IceConnectionString function.
ICElib will be responsible for freeing the reply data_ret and error_string_ret pointers with free().
The auth_data pointer may point to a volatile block of memory. If the data must be kept beyond this invocation of the callback, be sure to make a copy of it.
The IcePoAuthProc should return one of four values:
IcePoAuthHaveReply | A reply is available |
IcePoAuthRejected | Authentication rejected |
IcePoAuthFailed | Authentication failed |
IcePoAuthDoneCleanup | Done cleaning up |
IcePaAuthProc is the callback invoked for the client that received the Protocol Setup.
typedef IcePaAuthStatus (*IcePaAuthProc) ();
ice_conn | The ICE connection object. |
auth_state_ptr | A pointer to state for use by the authentication callback procedure. |
swap | If True, the auth_data may have to be byte swapped (depending on its contents). |
auth_datalen | The length (in bytes) of the protocol originator authentication data. |
auth_data | The authentication data from the protocol originator. |
reply_datalen ret | The length of the authentication data returned. |
reply_data_ret | The authentication data returned. |
error_string_rer | If authentication is rejected or fails, an error string is returned. |
Authentication may require several phases, depending on the authentication method. As a result, the IcePaAuthProc may be called more than once when authenticating a client, and some state will have to be maintained between each invocation. At the start of each Proxocol Setup, auth_datalen is zero, *auth_state_ptr is NULL, and the function should initialize its state and set this pointer. In subsequent invocations of the callback, the pointer should be used to get at any state previously stored by the callback.
If needed, the network ID of the client accepting the Protocol Setup can be obtained by calling the IceConnectionString function.
The auth data pointer may point to a volatile block of memory. If the data must
be kept beyond this invocation of the callback, be sure to make a copy of it.
ICElib will be responsible for freeing the reply_data_ret and error_string_ret pointers with free().
The IcePaAuthProc should return one of four values:
IcePaAuthContinue | Continue (or start) authentication |
IcePaAuthAccepted | Authenticalion accepted |
IcePaAuthRejected | Authentication rejected |
IcePaAuthFailed | Authentication failed |
In order for two clients to establish an ICE connection, one client has to be "waiting" for connections, and the other client has to initiate the connection. Most clients will initiate connections, so we discuss that first.
In order to open an ICE connection with another client (that is waiting for
connections), call the Ice Open Connection function.
network_ids_list | Specifies the network ID(s) of the other client. |
context | A pointer to an opaque object, or NULL. Used to determine if an ICE connection can be shared (see below). |
must_authenticate | If True, the other client may not bypass authentication. |
major_opcode check | Used to force a new ICE connection to be created (see below). |
error_length | Length of the error_string_ret argument passed in. |
error_string ret | Returns a null terminated error message, if any. error_string_ret points to user supplied memory. No more than error_length bytes are used. |
IceOpenConnection retums an opaque ICE connection object if it succeeds, NULL otherwise.
network_ids_list contains a list of network IDs separated by commas. An attempt will be made to use the first network ID. If that fails, an attempt will be made using the second network ID, and so on. Each network ID has the form...
tcp/<hostname>:<portnumber> | or | |
decent/<hostname>::<objname> | or | local<hostname>:<path> |
Most protocol libraries will have some sort of "open" function which should internally make a call into Ice Open Connection. When Ice Open Connection is called, it may be possible to use a previously opened ICE connection (if the target client is the same). However, there are cases in which shared ICE connection are not desired.
The context argument is used to determine if an ICE connection can be shared. If context is NULL, then the caller is always willing to share the connection. If context is not NULL, then the caller is not willing to use a previously opened ICE connection that has a different non-NULL context associated with it.
In addition, if major_opcode_check contains a non-zero major opcode value, a previously created ICE connection will be used only if the major opcode is not active on the connection. This can be used to force multiple ICE connection between two clients for the same protocol.
Any authentication requirements are handled internally by the ICE library. The method by which the authentication data is obtained is implementation dependent.*
After IceOpenConnection is called, the client is ready to send a Protocol Setup (provided that IceRegisterForProtocolSetup was called), or receive a Protocol Setup (provided that IceRegisterForProtocolReply was called).
The X Consortium's ICElib implementation uses an .ICEauthority file (see Appendix C).
Clients wishing to accept ICE connections must first call IceListenForConnections so they can listen for connections. A list of opaque "listen" objects are returned, one for each type of transport method that is available (for example, Unix Domain, TCP, DECnet, etc.).
count_ret | The number of listen objects returned. |
Iisten_obis ret | Returns a list of opaque listen objects. |
error_length | The length of the error_string_ret argument passed in. |
error_string_ret | Returns a null terminated error message, if any. error_string_ret points to user supplied memory. No more than error_length bytes are used. |
The return value of Ice Listen For Connections is zero for failure, and a positive value for success.
Call Ice FreeListenObjs to close and free the listen objects.
count | The number of listen objects. |
Iisten_objs | The listen objects. |
In order to detect a new connection on a listen object, select() must be called on the description associated with the listen object. To obtain the descriptor, call the IceGetListenConnectionNumber ffunction.
listen_obj | The listen object. |
To obtain the network ID string associated with a listen object, call the IceGetListenConnectionString function.
listen_obj | The listen object. |
A network ID has the form...
tcp/<hostname>:<portnumber> | or | |
decent/<hostname>::<objname> | or | |
local/<hostname>:<path> |
To compose a string containing a list of network IDs separated by commas (the format recognized by IceOpenConnection), call the IceComposeNetworkldList function.
count | The number of listen objects. |
Iisten obis | Thelistenobjects. |
Home |
---|
If authentication fails when a client attempts to open an ICE connection, and the
initiating client has not required authentication, a host based authentication procedure
may be invoked to provide a last chance for the client to connect. Each listen object has
such a callback associated with it, and this callback is set using the IceSetHostBasedAuthProc
function.
listen_obj | The listen object. |
host_based_auth_proc | The host based authentication procedure. |
By default, each listen object has no host based authentication procedure associated with it. Passing NULL for host_based_auth_proc turns off host based authentication if it was previously set.
typedef Bool (*IceHostBasedAuthProc) ();
host_name | The host name of the client that tried to open an ICE connection. |
host_name | is a string of the form ''protocol/hostname'' where protocol is one of {tcp, decent, local}. |
If IceHostBasedAuthProc returns True, access will be granted, even though the original authentication failed. Note that authentication can effectively be disabled by registering an IceHostBasedAuthProc which always returns True.
Host based authentication is also allowed al Protocol Setup lime. The callback
is specified in the IceRegisterForProtocolReply function discussed earlier.
After a connection attempt is detected on a listen object returned by IceListenForConnections, Ice Accept Connection should be called. This returns a new opaque ICE connection object.
liste_obj | The listen object on which a new connection was detected. |
status_ret | Return status information. |
The status_ret argument is set to one of the following values:
IceAcceptSuccess: | The accept operation succeeded. The function returns a new connection object. |
IceAcceptFailure: | The accept operation failed. The function returns NULL. |
IceAcceptBadMalloc: | A memory allocation failed. The function returns NULL. |
In general, in order to detect new connections, the application will call select() on the file descriptors associated with the listen objects. When a new connection is detected, the IceAcceptConnection function should be called. IceAcceptConnection may return a new ICE connection that is in a "pending" state. This is because before the connection can become valid, authentication may be necessary. Since the ICE library cannot block and wait for the connection to become valid (infinite blocking can occur if the connecting client does not act properly), the application must wait for the connection status to become "valid".
The following pseudo-code demonstrates how connections are accepted:
new_ice_conn = IceAcceptConnection (listen_obj);
status = IceConnectionStatus (new_ice_conn);
time_start = time_now;
while (status == IceConnectPending) { selectO on {new_ice_conn, all open connections} for (each ice_conn in the list of open connections) if (data ready on ice_com) { status = IceProcessMessages (ice_conn, NULL, NULL); if (status == IceProcessMessagesIOError) IceCloseConnection (ice_conn); } if (data ready on new_ice_conn) { /* *IceProcessMessages is called until the connection *is non-pending. Doing so handles the connection *setup request and any authentication requirements. */ IceProcessMessages (new_ice_conn, NULL, NULL); status = IceConnectionStatus (new_ice_com); } else { if ( time now - time_start > MAX_WAIT_TIME) status = Ice Connect Rejecled; } } if (status == Ice Connect Accepted) { Add new_ice_conn to the list of open connections } else { IceCloseConnection (new_ice_conn); }
After IceAcceptConnection is called and the connection has been validated, the
client is ready to receive a Protocol Setup (provided that IceRegisterForProtocolReply
was called), or send a Protocol Setup (provided that IceRegisterForProtocolSetup
was called).
To close an ICE connection created with IceOpenConnection or IceAcceptConnection,
call the IceCloseConnection function.
ice conn | The ICE connection to close. |
In order to actually close an ICE connection, the following conditions must be met:
IceCloseConnection returns one of the following values:
IceClosedNow: | The ICE connection was closed at this time. The watch procedures were invoked and the connection was freed. |
IceClosedASAP: | An IO error had occurred on the connection, but IceCloseConnection is being called within a nested IceProcessMessages. The watch procedures have been invoked at this time, but the connection will be freed as soon as possible (when the nesting level reaches zero and Ice Process Messages returns a status of IceProcessMessagesConnectionClosed ). |
IceConnectionlnUse: | The connection was not closed al this time because it is being used by other active protocols. |
IceStartedShutdownNegotiation: | The connection was not closed at this lime and shutdown negotiation started with the client on the other side of the ICE connection. When the connection is actually closed, IceProcessMessages will rector a status of IceProcessMessagesConnectionClosed. |
When it is known that the client on the other side of the ICE connection has terminated
the Connection without initiating shutdown negotiation, the IceSetShutdownNegotiation function
should be called to turn off shutdown negotiation. This will prevent IceCloseConnection
from writing to a broken connection.
ice_conn | A valid ICE connection object. |
negotiate | If False, shutdown negotiating will be turned off. |
In order to check the shutdown negotiation status of an ICE connection, call the IceCheckShutdown Negotiation function.
ice_conn | A valid ICE connection object. |
IceCheckShutdownNegotiation returns True if shutdown negotiation will take place on the connection, False otherwise. Negotiation is on by default for a connection. It can only be changed with the IceSetShutdownNegotiation function.
In order to add a watch procedure which will be called each time ICElib opens a new connection via IceOpenConnection or IceAcceptConnection, or closes a connection via IceCloseConnection, call the IceAddConnectionWatch function.
watch_proc | The watch procedure to invoke when ICElib opens or closes a Connection. |
client_data | This pointer will be passed to the watch procedure. |
The return value of IceAddConnectionWatch is zero for failure, and a positive value for success.
Note that several calls to IceOpenConnection might share the same ICE connection. In such a case, the watch procedure is only invoked when the connection is first created (after authentication succeeds). Similarly, since connections might be shared, the watch procedure is called only if IceCloseConnection actually closes the connection (right before the IceConn is freed).
The watch procedures are very useful for applications which need to add a file description to a select mask when a new connection is created, and remove the file descriptor when the connection is destroyed. Since connections are shared, knowing when to add and remove the file descriptor from the select mask would be difficult without the watch procedures.
Multiple watch procedures may be registered with the ICE library. No assumptions should be made about their order of invocation.
If one or more ICE connections were already created by the ICE library al the lime the watch procedure is registered, the watch procedure will instantly be invoked for each of these ICE connections (with the opening flag set to True).
The watch procedure is of type IceWatchProc.
typedef void (*IceWatchProc)();
ice_conn | The opened or closed ICE connection. Call IceConnectionNumber to get the file descriptor associated with this connection. |
client_data | Client data specified in the call to IceAddConnectionWatch. |
opening | If True, the connection is being opened. If False, the connection is being closed. |
watch_data | Can be used to save a pointer to client data. |
If opening is True, the client should set the *watch_data pointer to any data it may need to save until the connection is closed and the watch procedure is invoked again with opening set to False.
To remove a watch procedure, call the IceRemoveConnectionWatch function.
watch_proc | The watch procedure that was passed to IceAddConnectionWatch. |
cliens_data | The client_dara pointer that was passed to IceAddConnectionWatch. |
In order to activate a protocol on a given ICE connection, call the IceProtocolSetup function.
IceProlocolSetupStatus IceProtocolSetup(ice_conn, my_opcode, client_data,
must_authenticate, major_version ret, minor version_ret, vendor ret, release ret,
error_length, error_string ret)
IceConn ice_conn;
int my_opcode;
IcePointer client_data;
Bool must_authenticate;
int *major_version_ret;
int *minor_version_ret;
char **vendor_ret;
char **release_ret;
int error_length;
char *error_string_ret;
ice_conn | A valid ICE connection object. |
my_opcode | The major opcode of the protocol to be set up, as returned by IceRegisterForProtocolSetup. |
client_data | The client data stored in this pointer will be passed to the IcePoProcessMsgProc call back. |
must_authenticate | If True, the other client may not bypass authentication. |
major_version_ret | The major version of the protocol to be used is returned. |
minor version ret | The minor version of the protocol to be used is returned. |
vendor_ret | The vendor string specified by the protocol acceptor. |
release_ret | The release string specified by the protocol acceptor. |
error_length | Specifies the length of the error_string_ret argument passed in. |
error_string_ret | Returns a null terminated error message, if any. error_string_ret points to user supplied memory. No more than error_length bytes are used. |
The vendor_ret and release_ret strings should be freed with free() when no longer needed.
IceProtocolSetup returns one of the following values:
IceProtocolSetupSuccess: | major_version_ret, minor_version_ret, vendor_ret, release_ret are set. |
IceProtocolSetupFailure or IceProtocolSetupIOError: |
Check error_string_ret for failure reason. major_version_rel, minor_version_ret, vendor_ret, release_ret are NOT set. |
IceProtocolAlreadyActive: | This protocol is already active on this connection. major_version_ret, minor_version_ret, vendor_ret, release_ret are NOT set. |
In order to notify the ICE library when a given protocol will no longer be used on an ICE connection, call the IceProtocolShutdown function.
ice_conn | A valid ICE connection object. |
major_opcode | The major opcode of the protocol to shut down. |
The return value of IceProtocolShutdown is zero for failure, and a positive value for success.
Failure will occur if the major opcode was never registered OR the protocol of the major opcode was never "activated" on the connection. By "activated" we mean that a Protocol Setup succeeded on the connection. Note that ICE does not define how each sub-protocol triggers a protocol shutdown.
In order to process incoming messages on an ICE connection, the IceProcessMessages function should be called.
ice_conn | A valid ICE connection object. |
reply_wait | Indicates if a reply is being waited for. |
reply_ready_ret | If set to True on return, a reply is ready. |
This function is used in two ways. In the first a client may generate a message and "block" by calling IceProcessMessages repeatedly until it gets its reply. In the second case, a client calls IceProcessMessages with reply_wait set to NULL in response to select() showing that there is data to read on the ICE connection. The ICE library may process zero or more complete messages. Note that messages which are not "blocked" for are always processed by invoking callbacks.
IceReplyWaitlnfo contains the major/minor opcodes and sequence number of the message for which a reply is being awaited. It also contains a pointer to the reply message to be filled in (the protocol library should cast this IcePointer to the appropriate reply type). In most cases, the reply will have some fixed-size part, and the client waiting for the reply will have provided a pointer to a structure to hold this fixed-size data. If there is variable-length data, it would be expected that the IcePoProcessMsgProc callback will have to allocate additional memory and store pointer(s) to that memory in the fixed-size structure. If the entire data is variable length (e.g., a single variable-length string), then the client waiting for the reply would probably just pass a pointer to fixed-size space to hold a pointer, and the IcePoProcessMsgProc callback would allocate the storage and store the pointer. lt is the responsibility of the client receiving the reply to free up any memory allocated on its behalf.
typedef struct { unsigned long sequence_of_request; int major_opcode_of_request; int minor_opcode_of_request; IcePointer reply; } IceReplyWaitInfo;
If reply_wait is not NULL and IceProcessMessages has a reply or error to return in response to this reply_wait (i.e. no callback was generated), then the reply_ready_ret argument will be set to True.
If reply wait is NULL, then the caller may also pass NULL for reply_ready_ret and be guaranteed that no value will be stored in this pointer.
IceProcessMessages returns one of the following values:
IceProcessMessagesSuccess: | No error occurred. |
IceProcessMessageslOError: | An IO error occurred. The caller must explicitly close the connection by calling IceCloseConnection. |
IceProcessMessagesConnectionClosed: | The ICE connection has been closed (closing of the connection was deferred because of shutdown negotiation, or because the IceProcessMessages nesting level was not zero). Do not a[tempt to access the ICE connection at this point, since it has been freed. |
To send a Ping message to the client on the other side of the ICE connection, call the IcePing function.
ice_conn | A valid ICE connection object. |
ping_reply_proc | The callback to invoke when the Ping reply arrives. |
client_data | This pointer will be passed to the IcePingReplyProc callback. |
The return value of IcePing is zero for failure, and a positive value for success.
When IceProcessMessages processes the Ping reply, it will invoke the IcePingReplyProc callback.
typedef void (*IcePingReplyProc)();
ice_conn | The ICE connection object. |
client_data | The client data specified in the call to IcePing. |
IceConnectStatus IceConnectionStatus ( ice conn )
IceConn ice_conn;
Returns the status of an ICE connection. The possible return values are:
IceConnectPending: | The connection is not valid yet (i.e. authentication is taking place). Only relevant to connections created by IceAcceptConnection. |
IceConnectAccepted: | The connection has been accepted. Only relevant to connections created by IceAcceptConnection. |
IceConnectRejected: | The connection had been rejected (i.e. authentication failed). Only relevant to connections created by IceAcceptConnection. |
IceConnectIOError: | An IO error has occurred on the connection. |
Returns the ICE library vendor identification for the other side of the connection. The string should be freed with a call to free() when no longer needed.
Returns the release identification of the ICE library on the other side of the
connection. The string should be freed with a call to free() when no longer needed.
Returns the major version of the ICE protocol on this connection.
Returns the minor version of the ICE protocol on this connection.
Returns the file descriptor of this ICE connection.
Returns the network ID of the client which accepted this connection. The string should
be freed with a call to free() when no longer needed.
Returns the sequence number of the last message sent on this ICE connection.
Returns the sequence number of the last message received on this ICE connection.
Returns True if byte swapping is necessary when reading messages on the ICE
connection.
Returns the context associated with a connection created by IceOpenConnection.
All ICE messages have a standard 8 byte header. The ICElib macros which read and write messages rely on the following naming convention for message headers:
CARD8 | major_opcode; | |
CARD8 | minor_opcode; | |
CARD8 | data[2]; | |
CARD32 | length B32; |
The 3rd and 4th bytes of the message header can be used as needed. The length field is
specified in units of 8 bytes.
The ICE library maintains an output buffer used for generating messages. Protocol libraries layered on top of ICE may choose to batch messages together and flush the output buffer at appropriate times.
If an IO error has occurred on an ICE connection, all write operations will be ignored. Refer to the section titled Error Handling for more discussion on handling IO errors.
To get the size of the ICE output buffer, call the IceGetOutBufSize function.
ice_conn | A valid ICE connection object. |
To flush the ICE output buffer, call the IceFlush function.
ice_conn | A valid ICE connection object. |
Note that the output buffer may be implicitly flushed if there is insufficient space to generate a message.
The following macros can be used to generate ICE messages:
ice_conn | A valid ICE connection object. |
major_opcode | The major opcode of the message. |
minor_opcode | The minor opcode of the message. |
header_size | The size of the message header (in bytes). |
<C data_type> | The actual C data type of the message header. |
pmsg | The message header pointer. After this macro is called, the library can store data in the message header. |
IceGetHeader is used to set up a message header on an ICE connection. It sets
the major and minor opcodes of the message, and initializes the message's length to the
length of the header. If additional variable length data follows, the message's length
field should be updated.
ice_conn | A valid ICE connection object. |
major_opcode | The major opcode of the message. |
minor_opcode | The minor opcode of the message. |
header_size | The size of the message header(in bytes). |
extra | The size of the extra data beyond the header (in 8 byte units). |
<C_data_type> | The actual C data type of the message header. |
pmsg | The message header pointer. After this macro is called, the library can store data in the message header. |
pdata | Returns a pointer to the ICE output buffer which points immediately after the message header. The variable length data should be stored here. If there was not enough room in the ICE output buffer, pdata is set to NULL. |
IceGetHeaderExtra is used to generate a message with a fixed (and relatively small) amount of variable length data. The complete message must fit in the ICE output buffer.
ice_conn | A valid ICE connection object. |
major_opcode | The major opcode of the message. |
minor_opcode | The minor opcode of the message. |
IceSimpleMessage is used to generate a message which is identical in size to the
ICE header message, and has no additional data.
ice_conn | A valid ICE connection object. |
offending_major_opcode | The major opcode of the protocol in which an error was detected. |
offending_major_opcode | The major opcode of the protocol in which an error was detected. |
offending_sequence_num | The sequence number of the message that caused the error. |
severity | IceCanContinue, IceFatalToProtocol, or IceFatalToConnection. |
error_class | The error class. See below. |
data_length | Length of data (in 8 byte units) IO be written after the header. |
IceErrorHeader sets up an error message header.
Note that the two clients connected by ICE may be using different major opcodes for a given protocol. The offending_major_opcode passed to this macro is the major opcode of the protocol for the client sending the error message.
Generic errors which are common to all protocols have classes in the range 0x8000..0xFFFF. See the Inter-Client Exchange Protocol document for more details.
IceBadMinor | 0x8000 |
IceBadState | 0x8001 |
IceBadLength | 0x8002 |
IceBadValue | 0x8003 |
Per-protocol errors have classes in the range 0x0000-0x7fff.
To write data to an ICE connection, use the IceWriteData macro. If the data fits into the ICE output buffer, it is copied there. Otherwise, the ICE output buffer is flushed and the data is directly sent.
This macro is used in conjunction with IceGetHeader and IceErrorHeader.
ice_conn | A valid ICE connection object. |
bytes | The number of bytes to write. |
data | The data to write. |
To write data as 16 bit quantities, use the IceWriteDatal6 macro.
ice_conn | A valid ICE connection object. |
bytes | The number of bytes to write. |
data | The data to write. |
To write data as 32 bit quantities, use the IceWriteData32 macro.
ice_conn | A valid ICE connection object. |
bytes | The number of bytes to write. |
data | The data to write. |
To bypass copying data to the ICE output buffer, use the IceSendData to directly
send date over the network connection. If necessary, the ICE output buffer is first
flushed.
ice_conn | A valid ICE connection object. |
bytes | The number of bytes to send. |
data | The data to send. |
To force 32 or 64 bit alignment, use the IceWritePad macro. A maximum of 7 pad bytes can be specified.
ice_conn | A valid ICE connection object. |
bytes | The number of pad bytes. |
Home |
---|
The ICE library maintains an input buffer used for reading messages. If the ICE library
chooses to perform non-blocking reads (this is implementation dependent), then for every
read operation that it makes, zero or more complete messages may be read into the input
buffer. As a result, for all of the macros described in this section which
"read" messages, an actual read operation will occur on the connection only if
the data is not already present in the input buffer.
To get the size of the ICE input buffer, call the IceGetlnBufSize function.
ice conn | A valid ICE connection object. |
When reading messages, care must be taken to check for IO errors. If any IO error
occurs in reading any part of a message, the message should be thrown out. After using any
of the macros described below for reading messages, the IceValidIO macro can be
used to check if an IO error occurred on the connection. After an IO error has occurred on
an ICE connection, all read operations will be ignored. Refer to the section tilled Error Handling for more discussion on handling IO
errors.
The following macros can be used to read ICE messages:
ice_conn | A valid ICE connection object. |
<C data_type> | The actual C data type of the message header. |
pmsg | This pointer is set to the message header. |
Ice Read Simple Message is used for messages which are identical in size to the 8 byte ICE header, but use the spare 2 bytes in the header to encode additional data. Note that the ICE library always reads in these first 8 bytes so it can obtain the major opcode of the message. IceReadSimpleMessage simply returns a pointer to these 8 bytes, it does not actually read any data into the input buffer.
For a message with variable length data, there are two ways of reading the message. One method involves reading the complete message in one pass using IceReadCompleteMessage. The second method involves reading the message header (note that this may be larger than the 8 byte ICE header), then reading the variable length data in chunks (see IceReadMessageHeader and IceReadData).
ice_conn | A valid ICE connection object. |
header_size | The size of the message header (in bytes). |
<C data_type> | The actual C data type of the message header. |
pmsg | This pointer is set to the message header. |
pdata | This pointer is set to the variable length data of the message. |
If the ICE input buffer has sufficient space, IceReadCompleteMessage will read
the complete message into the ICE input buffer. Otherwise, a buffer will be allocated to
hold the variable length data. After the call, the pdata argument should be checked
against NULL to make sure that there was sufficient memory to allocate the buffer.
After calling IceReadCompleteMessage and processing the message, IceDisposeCompleteMessage should be called.
ice conn | A valid ICE connection object. |
pdata | The pointer to the variable length data returned in IceReadCompleteMessage. |
If a buffer had to be allocated to hold the variable length data (because it didn't fit in the ICE input buffer), it is freed here by ICElib.
ice_conn | A valid ICE connection object. |
header_size | The size of the message header (in bytes). |
<C_data_type> | The actual C data type of the message header. |
pmsg | This pointer is set to the message header. |
IceReadMessageHeader reads just the message header. The rest of the data should be read with the IceReadData family of macros. This method of reading a message should be used when the variable length data must be read in chunks.
To read data directly into a user supplied buffer, use the IceReadData macro.
ice_conn | Avalid ICE connection object. |
bytes | The number of bytes to read. |
pdata | The data is read into this user supplied buffer |
To read data as 16 bit quantities, use the IceReadData16 macro
ice_conn | A valid ICE connection object. |
swap | If True, the values will be byte swapped |
bytes | The number of bytes to read. |
pdata | The data is read into this user supplied buffer. |
To read data as 32 bit quantities, use the IceReadData32 macro
ice_conn | A valid ICE connection object |
swap | If True, the values will be byte swapped |
bytes | The number of bytes to read |
pdata | The data is read into this user supplied buffer |
To force 32 or 64 bit alignment, use the IceReadPad macro A maximum of 7 pad bytes can be specified
ice_conn | A valid ICE connection object |
bytes | The number of pad bytes |
There are two default error handlers in ICElib: one to handle typically fatal
conditions (for example, a connection dying because a machine crashed) and one to handle
ICE-specific protocol errors These error handlers can be changed to user-supplied routines
if you prefer your own error handling and can be changed as often as you like.
To set the ICE error handler, use IceSetErrorHandler.
handler | The ICE error handler. Pass NULL to restore the default handler. |
IceSetErrorHandler returns the previous error handler.
The ICE error handler is invoked when an unexpected ICE protocol error (major opcode 0) is encountered The action of the default handler is to print an explanatory message to stderr and if the severity is fatal, call exit() with a non-zero value If exiting is undesirable, the application should register its own error handler
Note that errors in other protocol domains should be handled by their respective libraries (these libraries should have their own error handlers)
An ICE error handler has the type of IceErrorHandler
typedef void (*IceErrorHandler)();
ice_conn | The ICE connection object |
swap | A flag which indicates if the values need byte swapping |
offending minor_opcode | The ICE minor opcode of the offending message. |
offending_sequence_nurn | The sequence number of the offending message. |
error class | The error class of the offending message |
severity | IceCanContinue, IceFatalToProtocol, or IceFatalToConnection |
values | Any additional error values specific to the minor opcode and class |
The following error classes are defined at the ICE level Refer to the Inter-Client Exchange Protocol document for more details.
IceBadMinor, IceBadState, IceBadLength, IceBadValue, IceBadMajor, IceNoAuth, IceNoVersion, IceSetupFailed, IceAuthRejected, IceAuthFailed, IceProtocolDuplicate, IceMajorOpcodeDuplicate, or IceUnknownProtocol.
To handle fatal I/O errors, use IceSetlOErrorHandler
handler | The I/O error handler Pass NULL to restore the default handler. |
IceSetIOErrorHandler returns the previous IO error handler.
An ICE I/O error handler has the type of IceIOErrorHandler:
typedef void (*IceIOErrorHandler)();
ice_conn | The ICE connection object |
There are two ways of handling IO errors in ICElib
In the first model, the IO error handler does whatever is necessary to respond to the IO error and then returns, but it does not call IceCloseConnection The ICE connection is given a "bad IO" status, and all future reads and writes to the connection are ignored The next time IceProcessMessages is called it A ill return a status of IceProcessMessagesIOError At that time, the application should call IceCloseConnection.
In the second model, the IO error handler does call IceCloseConnection, and then uses the longjmp() call to get back to the application's main event loop setjmp() and longjmp() may not work; properly on all platforms and special care must be taken to avoid memory leaks, so this second model is less desirable.
Before the application I/O error handler is invoked, protocol libraries that were interested in being notified of I/O errors will have their IceIOErrorProc handlers invoked. This handler is set up in the protocol registration functions (see IceRegisterForProtocolSetup and IceRegisterForProtocolReply), and could be used to clean up state specific to the protocol.
typedef void (*IceIOErrorProc)();
ice_conn | The ICE connection object. |
Note that every IceIOErrorProc callback must return This is required because each active protocol must be notified of the broken connection, and the application IO error handler must be invoked afterwards.
To declare that multiple threads in an application will be using the ICE library, call IcelnitThreads.
Status IceInitThreads()
The IceInitThreads function must be the first ICElib function a multi-threaded program calls It must complete before any other ICElib call is made IcelnilThreads returns a non-zero status if and only if it was able to successfully initialize the threads package It is safe to call this function more than once, although the threads package will only be initialized once.
Protocol libraries layered on top of ICElib will have to lock critical sections of code that access an ICE connection (for example, when generating messages) Two calls, which are generally implemented as macros, are provided:
ice_conn | The ICEconnection. |
To keep an ICE connection locked across several ICElib calls, applications use IceAppLockConn and IceAppUnlockConn .
ice_conn | The ICE connection to lock. |
The IceAppLockConn function completely locks out other threads from ICElib until IceAppLockConn is called. Other threads attempting to use ICElib will block. If the program has not previously called IceInitThreads, IceAppLockConn has no effect.
ice_conn | The ICE connection to unlock. |
The IceAppUnlockConn function allows other threads to complete ICElib calls which were blocked by a previous call to IceAppLockConn from this thread. If the program has not previously called IceInitThreads, IceAppUnlockConn has no effect.
To allocate scratch space (for example, when generating messages with variable data),
use the IceAllocScratch function. Each ICE connection has one scratch space
associated with it. The scratch space starts off as empty and grows as needed. The
contents of the scratch space is not guaranteed to be preserved after any ICElib function
is called.
ice_conn | A valid ICE connection object. |
size | The number of bytes required. |
The memory returned by IceAllocScratch should not be freed by the caller! The ICE library will free the memory when the ICE connection is closed.
Contents | Previous Chapter | Next Chapter |