?????????? ????????? - ??????????????? - /home/agenciai/public_html/cd38d8/libICE.zip
???????
PK t��[$'V� E E ice.xmlnu �[��� <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ <!ENTITY % defs SYSTEM "defs.ent"> %defs; ]> <!-- lifted from troff+ms+XMan by doclifter --> <book id="ice"> <bookinfo> <title>Inter-Client Exchange (ICE) Protocol</title> <subtitle>X Consortium Standard</subtitle> <releaseinfo>X Version 11, Release &fullrelvers;</releaseinfo> <authorgroup> <author> <firstname>Robert</firstname><surname>Scheifler</surname> <affiliation><orgname>X Consortium</orgname></affiliation> </author> <othercredit> <firstname>Jordan</firstname><surname>Brown</surname> <affiliation><orgname>Quarterdeck Office Systems</orgname></affiliation> </othercredit> </authorgroup> <releaseinfo>Version 1.1</releaseinfo> <copyright> <year>1993</year><year>1994</year> <holder>X Consortium</holder> </copyright> <legalnotice> <para>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 Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:</para> <para>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.</para> <para>THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 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.</para> <para>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.</para> <para>X Window System is a trademark of The Open Group.</para> </legalnotice> <abstract> <para> There are numerous possible protocols that can be used for communication among clients. They have many similarities and common needs, including authentication, version negotiation, data typing, and connection management. The <emphasis remap='I'> Inter-Client Exchange</emphasis> (ICE) protocol is intended to provide a framework for building such protocols. Using ICE reduces the complexity of designing new protocols and allows the sharing of many aspects of the implementation. </para> </abstract> </bookinfo> <chapter id='Purpose_and_Goals'> <title>Purpose and Goals</title> <para> In discussing a variety of protocols -- existing, under development, and hypothetical -- it was noted that they have many elements in common. Most protocols need mechanisms for authentication, for version negotiation, and for setting up and taking down connections. There are also cases where the same two parties need to talk to each other using multiple protocols. For example, an embedding relationship between two parties is likely to require the simultaneous use of session management, data transfer, focus negotiation, and command notification protocols. While these are logically separate protocols, it is desirable for them to share as many pieces of implementation as possible.</para> <para>The <emphasis remap='I'> Inter-Client Exchange </emphasis> (ICE) protocol provides a generic framework for building protocols on top of reliable, byte-stream transport connections. It provides basic mechanisms for setting up and shutting down connections, for performing authentication, for negotiating versions, and for reporting errors. The protocols running within an ICE connection are referred to here as <emphasis remap='I'>subprotocols.</emphasis> ICE provides facilities for each subprotocol to do its own version negotiation, authentication, and error reporting. In addition, if two parties are communicating using several different subprotocols, ICE will allow them to share the same transport layer connection.</para> </chapter> <chapter id='Overview_of_the_Protocol'> <title>Overview of the Protocol</title> <para>Through some mechanism outside ICE, two parties make themselves known to each other and agree that they would like to communicate using an ICE subprotocol. ICE assumes that this negotation includes some notion by which the parties will decide which is the <quote>originating</quote> party and which is the <quote>answering</quote> party. The negotiation will also need to provide the originating party with a name or address of the answering party. Examples of mechanisms by which parties can make themselves known to each other are the X selection mechanism, environment variables, and shared files.</para> <para>The originating party first determines whether there is an existing ICE connection between the two parties. If there is, it can re-use the existing connection and move directly to the setup of the subprotocol. If no ICE connection exists, the originating party will open a transport connection to the answering party and will start ICE connection setup.</para> <para>The ICE connection setup dialog consists of three major parts: byte order exchange, authentication, and connection information exchange. The first message in each direction is a <function>ByteOrder</function> message telling which byte order will be used by the sending party in messages that it sends. After that, the originating party sends a <function>ConnectionSetup</function> message giving information about itself (vendor name and release number) and giving a list of ICE version numbers it is capable of supporting and a list of authentication schemes it is willing to accept. Authentication is optional. If no authentication is required, the answering party responds with a <function>ConnectionReply</function> message giving information about itself, and the connection setup is complete.</para> <para>If the connection setup is to be authenticated, the answering party will respond with an <function>AuthenticationRequired</function> message instead of a <function>ConnectionReply</function> message. The parties then exchange <function>AuthenticationReply</function> and <function>AuthenticationNextPhase</function> messages until authentication is complete, at which time the answering party finally sends its <function>ConnectionReply</function> message.</para> <para>Once an ICE connection is established (or an existing connection reused), the originating party starts subprotocol negotiation by sending a <function>ProtocolSetup</function> message. This message gives the name of the subprotocol that the parties have agreed to use, along with the ICE major opcode that the originating party has assigned to that subprotocol. Authentication can also occur for the subprotocol, independently of authentication for the connection. Subprotocol authentication is optional. If there is no subprotocol authentication, the answering party responds with a <function>ProtocolReply</function> message, giving the ICE major opcode that it has assigned for the subprotocol.</para> <para>Subprotocols are authenticated independently of each other, because they may have differing security requirements. If there is authentication for this particular subprotocol, it takes place before the answering party emits the <function>ProtocolReply</function> message, and it uses the <function>AuthenticationRequired</function> <function>AuthenticationReply</function> and <function>AuthenticationNextPhase</function> messages, just as for the connection authentication. Only when subprotocol authentication is complete does the answering party send its <function>ProtocolReply</function> message.</para> <para>When a subprotocol has been set up and authenticated, the two parties can communicate using messages defined by the subprotocol. Each message has two opcodes: a major opcode and a minor opcode. Each party will send messages using the major opcode it has assigned in its <function>ProtocolSetup</function> or <function>ProtocolReply</function> message. These opcodes will, in general, not be the same. For a particular subprotocol, each party will need to keep track of two major opcodes: the major opcode it uses when it sends messages, and the major opcode it expects to see in messages it receives. The minor opcode values and semantics are defined by each individual subprotocol.</para> <para>Each subprotocol will have one or more messages whose semantics are that the subprotocol is to be shut down. Whether this is done unilaterally or is performed through negotiation is defined by each subprotocol. Once a subprotocol is shut down, its major opcodes are removed from use; no further messages on this subprotocol should be sent until the opcode is reestablished with <function>ProtocolSetup</function> </para> <para>ICE has a facility to negotiate the closing of the connection when there are no longer any active subprotocols. When either party decides that no subprotocols are active, it can send a <function>WantToClose</function> message. If the other party agrees to close the connection, it can simply do so. If the other party wants to keep the connection open, it can indicate its desire by replying with a <function>NoClose</function> message.</para> <!-- XXX \- Note that it's likely that both parties will WantToClose at once. --> <para>It should be noted that the party that initiates the connection isn't necessarily the same as the one that initiates setting up a subprotocol. For example, suppose party A connects to party B. Party A will issue the <function>ConnectionSetup</function> message and party B will respond with a <function>ConnectionReply</function> message. (The authentication steps are omitted here for brevity.) Typically, party A will also issue the <function>ProtocolSetup</function> message and expect a <function>ProtocolReply</function> from party B. Once the connection is established, however, either party may initiate the negotiation of a subprotocol. Continuing this example, party B may decide that it needs to set up a subprotocol for communication with party A. Party B would issue the <function>ProtocolSetup</function> message and expect a <function>ProtocolReply</function> from party A.</para> <!-- .nH 1 "Data Types" --> </chapter> <chapter id='Data_Types'> <title>Data Types</title> <para>ICE messages contain several types of data. Byte order is negotiated in the initial connection messages; in general data is sent in the sender's byte order and the receiver is required to swap it appropriately. In order to support 64-bit machines, ICE messages are padded to multiples of 8 bytes. All messages are designed so that fields are <quote>naturally</quote> aligned on 16-, 32-, and 64-bit boundaries. The following formula gives the number of bytes necessary to pad <emphasis remap='I'>E</emphasis> bytes to the next multiple of <emphasis remap='I'>b</emphasis>:</para> <literallayout remap='DS'> pad(<emphasis remap='I'>E</emphasis>, <emphasis remap='I'>b</emphasis>) = (<emphasis remap='I'>b</emphasis> - (<emphasis remap='I'>E</emphasis> mod <emphasis remap='I'>b</emphasis>)) mod <emphasis remap='I'>b</emphasis> </literallayout> <sect1 id='Primitive_Types'> <title>Primitive Types</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Type Name</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry>CARD8</entry> <entry>8-bit unsigned integer</entry> </row> <row> <entry>CARD16</entry> <entry>16-bit unsigned integer</entry> </row> <row> <entry>CARD32</entry> <entry>32-bit unsigned integer</entry> </row> <row> <entry>BOOL</entry> <entry><para><function>False</function> or <function>True</function></para></entry> </row> <row> <entry>LPCE</entry> <entry>A character from the X Portable Character Set in Latin Portable Character Encoding</entry> </row> </tbody> </tgroup> </informaltable> </sect1> <sect1 id='Complex_Types'> <title>Complex Types</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Type Name</entry> <entry>Type</entry> </row> </thead> <tbody> <row> <entry>VERSION</entry> <entry>[Major, minor: CARD16]</entry> </row> <row> <entry>STRING</entry> <entry>LISTofLPCE</entry> </row> </tbody> </tgroup> </informaltable> <para>LISTof<type> denotes a counted collection of <type>. The exact encoding varies depending on the context; see the encoding section.</para> <!-- .nH 1 "Message Format" --> </sect1> <sect1 id='Message_Format'> <title>Message Format</title> <para>All ICE messages include the following information:</para> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Field Type</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry>CARD8</entry> <entry>protocol major opcode</entry> </row> <row> <entry>CARD8</entry> <entry>protocol minor opcode</entry> </row> <row> <entry>CARD32</entry> <entry>length of remaining data in 8-byte units</entry> </row> </tbody> </tgroup> </informaltable> <para>The fields are as follows:</para> <variablelist> <varlistentry> <term>Protocol major opcode</term> <listitem> <para> This specifies what subprotocol the message is intended for. Major opcode 0 is reserved for ICE control messages. The major opcodes of other subprotocols are dynamically assigned and exchanged at protocol negotiation time. </para> </listitem> </varlistentry> <varlistentry> <term>Protocol minor opcode</term> <listitem> <para> This specifies what protocol-specific operation is to be performed. Minor opcode 0 is reserved for Errors; other values are protocol-specific. </para> </listitem> </varlistentry> <varlistentry> <term>Length of data in 8-byte units</term> <listitem> <para> This specifies the length of the information following the first 8 bytes. Each message-type has a different format, and will need to be separately length-checked against this value. As every data item has either an explicit length, or an implicit length, this can be easily accomplished. Messages that have too little or too much data indicate a serious protocol failure, and should result in a <function>BadLength</function> error. </para> </listitem> </varlistentry> </variablelist> </sect1> </chapter> <chapter id='Overall_Protocol_Description'> <title>Overall Protocol Description</title> <para> Every message sent in a given direction has an implicit sequence number, starting with 1. Sequence numbers are global to the connection; independent sequence numbers are <emphasis remap='I'>not</emphasis> maintained for each protocol.</para> <para>Messages of a given major-opcode (i.e., of a given protocol) must be responded to (if a response is called for) in order by the receiving party. Messages from different protocols can be responded to in arbitrary order.</para> <para>Minor opcode 0 in every protocol is for reporting errors. At most one error is generated per request. If more than one error condition is encountered in processing a request, the choice of which error is returned is implementation-dependent. </para> <para><function>Error</function></para> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para>CARD8</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> {<symbol role='Pn'>CanContinue</symbol>, <function>FatalToProtocol</function> <function>FatalToConnection</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>sequence-number</emphasis>:</term> <listitem> <para>CARD32</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>class</emphasis>:</term> <listitem> <para>CARD16</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>value(s)</emphasis>:</term> <listitem> <para><dependent on major/minor opcode and class></para> </listitem> </varlistentry> </variablelist> <para> This message is sent to report an error in response to a message from any protocol. The <function>Error</function> message exists in all protocol major-opcode spaces; it is minor-opcode zero in every protocol. The minor opcode of the message that caused the error is reported, as well as the sequence number of that message. The severity indicates the sender's behavior following the identification of the error. <function>CanContinue</function> indicates the sender is willing to accept additional messages for this protocol. <function>FatalToProcotol</function> indicates the sender is unwilling to accept further messages for this protocol but that messages for other protocols may be accepted. <function>FatalToConnection</function> indicates the sender is unwilling to accept any further messages for any protocols on the connection. The sender is required to conform to specified severity conditions for generic and ICE (major opcode 0) errors; see <xref linkend='Generic_Error_Classes' xrefstyle='select: title'/> <xref linkend='ICE_Error_Classes' xrefstyle='select: title'/> . The class defines the generic class of error. Classes are specified separately for each protocol (numeric values can mean different things in different protocols). The error values, if any, and their types vary with the specific error class for the protocol. </para> </chapter> <chapter id='ICE_Control_Subprotocol____Major_Opcode_0_0'> <title>ICE Control Subprotocol -- Major Opcode 0</title> <para> Each of the ICE control opcodes is described below. Most of the messages have additional information included beyond the description above. The additional information is appended to the message header and the length field is computed accordingly. </para> <para> In the following message descriptions, <quote>Expected errors</quote> indicates errors that may occur in the normal course of events. Other errors (in particular <function>BadMajor</function> <function>BadMinor</function> <function>BadState</function> <function>BadLength</function> <function>BadValue</function> <function>ProtocolDuplicate</function> and <function>MajorOpcodeDuplicate</function> might occur, but generally indicate a serious implementation failure on the part of the errant peer. </para> <para><function>ByteOrder</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>byte-order</emphasis>:</term> <listitem> <para> {<symbol role='Pn'>MSBfirst</symbol>, <function>LSBfirst</function> </para> </listitem> </varlistentry> </variablelist> <para> Both parties must send this message before sending any other, including errors. This message specifies the byte order that will be used on subsequent messages sent by this party. </para> <note> <para> Note: If the receiver detects an error in this message, it must be sure to send its own <function>ByteOrder</function> message before sending the <function>Error</function>. </para> </note> <para><function>ConnectionSetup</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>versions</emphasis>:</term> <listitem> <para>LISTofVERSION</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>must-authenticate</emphasis>:</term> <listitem> <para>BOOL</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>authentication-protocol-names</emphasis>:</term> <listitem> <para>LISTofSTRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term>Responses:</term> <listitem> <para> <function>ConnectionReply</function>, <function>AuthenticationRequired</function> (See note) </para> </listitem> </varlistentry> <varlistentry> <term>Expected errors:</term> <listitem> <para> <function>NoVersion</function>, <function>SetupFailed</function>, <function>NoAuthentication</function>, <function>AuthenticationRejected</function>, <function>AuthenticationFailed</function> </para> </listitem> </varlistentry> </variablelist> <para> The party that initiates the connection (the one that does the "connect()") must send this message as the second message (after <function>ByteOrder</function> on startup. </para> <para> Versions gives a list, in decreasing order of preference, of the protocol versions this party is capable of speaking. This document specifies major version 1, minor version 0. </para> <para> If must-authenticate is <function>True</function> the initiating party demands authentication; the accepting party <emphasis remap='I'>must</emphasis> pick an authentication scheme and use it. In this case, the only valid response is <function>AuthenticationRequired</function> </para> <para> If must-authenticate is <function>False</function> the accepting party may choose an authentication mechanism, use a host-address-based authentication scheme, or skip authentication. When must-authenticate is <function>False</function> <function>ConnectionReply</function> and <function>AuthenticationRequired</function> are both valid responses. If a host-address-based authentication scheme is used, <function>AuthenticationRejected</function> and <function>AuthenticationFailed</function> errors are possible. </para> <para> Authentication-protocol-names specifies a (possibly null, if must-authenticate is <function>False</function> list of authentication protocols the party is willing to perform. If must-authenticate is <function>True</function> presumably the party will offer only authentication mechanisms allowing mutual authentication. </para> <para> Vendor gives the name of the vendor of this ICE implementation. </para> <para> Release gives the release identifier of this ICE implementation. </para> <para><function>AuthenticationRequired</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>authentication-protocol-index</emphasis>:</term> <listitem> <para>CARD8</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data</emphasis>:</term> <listitem> <para><specific to authentication protocol></para> </listitem> </varlistentry> <varlistentry> <term>Response:</term> <listitem> <para><function>AuthenticationReply</function></para> </listitem> </varlistentry> <varlistentry> <term>Expected errors:</term> <listitem> <para> <function>AuthenticationRejected</function>, <function>AuthenticationFailed</function> </para> </listitem> </varlistentry> </variablelist> <para> This message is sent in response to a <function>ConnectionSetup</function> or <function>ProtocolSetup</function> message to specify that authentication is to be done and what authentication mechanism is to be used. </para> <para> The authentication protocol is specified by a 0-based index into the list of names given in the <function>ConnectionSetup</function> or <function>ProtocolSetup</function> Any protocol-specific data that might be required is also sent. </para> <para><function>AuthenticationReply</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>data</emphasis>:</term> <listitem> <para><specific to authentication protocol></para> </listitem> </varlistentry> <varlistentry> <term>Responses:</term> <listitem> <para> <function>AuthenticationNextPhase</function>, <function>ConnectionReply</function>, <function>ProtocolReply</function> </para> </listitem> </varlistentry> <varlistentry> <term>Expected errors:</term> <listitem> <para> <function>AuthenticationRejected</function>, <function>AuthenticationFailed</function>, <function>SetupFailed</function> </para> </listitem> </varlistentry> </variablelist> <para> This message is sent in response to an <function>AuthenticationRequired</function> or <function>AuthenticationNextPhase</function> message, to supply authentication data as defined by the authentication protocol being used. </para> <para> Note that this message is sent by the party that initiated the current negotiation -- the party that sent the <function>ConnectionSetup</function> or <function>ProtocolSetup</function> message. </para> <para> <function>AuthenticationNextPhase</function> indicates that more is to be done to complete the authentication. If the authentication is complete, <function>ConnectionReply</function> is appropriate if the current authentication handshake is the result of a <function>ConnectionSetup</function> and a <function>ProtocolReply</function> is appropriate if it is the result of a <function>ProtocolSetup</function>. </para> <para><function>AuthenticationNextPhase</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>data</emphasis>:</term> <listitem> <para><specific to authentication protocol></para> </listitem> </varlistentry> <varlistentry> <term>Response:</term> <listitem> <para><function>AuthenticationReply</function></para> </listitem> </varlistentry> <varlistentry> <term>Expected errors:</term> <listitem> <para> <function>AuthenticationRejected</function>, <function>AuthenticationFailed</function> </para> </listitem> </varlistentry> </variablelist> <para> This message is sent in response to an <function>AuthenticationReply</function> message, to supply authentication data as defined by the authentication protocol being used. </para> <para><function>ConnectionReply</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>version-index</emphasis>:</term> <listitem> <para>CARD8</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> </variablelist> <para> This message is sent in response to a <function>ConnectionSetup</function> or <function>AuthenticationReply</function> message to indicate that the authentication handshake is complete. </para> <para> Version-index gives a 0-based index into the list of versions offered in the <function>ConnectionSetup</function> message; it specifies the version of the ICE protocol that both parties should speak for the duration of the connection. </para> <para>Vendor gives the name of the vendor of this ICE implementation.</para> <para> Release gives the release identifier of this ICE implementation. </para> <para><function>ProtocolSetup</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>protocol-name</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major-opcode</emphasis>:</term> <listitem> <para>CARD8</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>versions</emphasis>:</term> <listitem> <para>LISTofVERSION</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>must-authenticate</emphasis>:</term> <listitem> <para>BOOL</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>authentication-protocol-names</emphasis>:</term> <listitem> <para>LISTofSTRING</para> </listitem> </varlistentry> <varlistentry> <term>Responses:</term> <listitem> <para> <function>AuthenticationRequired</function>, <function>ProtocolReply</function> </para> </listitem> </varlistentry> <varlistentry> <term>Expected errors:</term> <listitem> <para> <function>UnknownProtocol</function>, <function>NoVersion</function>, <function>SetupFailed</function>, <function>NoAuthentication</function>, <function>AuthenticationRejected</function>, <function>AuthenticationFailed</function> </para> </listitem> </varlistentry> </variablelist> <para> This message is used to initiate negotiation of a protocol and establish any authentication specific to it. </para> <para> Protocol-name gives the name of the protocol the party wishes to speak. </para> <para> Major-opcode gives the opcode that the party will use in messages it sends. </para> <para> Versions gives a list of version numbers, in decreasing order of preference, that the party is willing to speak. </para> <para> Vendor and release are identification strings with semantics defined by the specific protocol being negotiated. </para> <para> If must-authenticate is <function>True</function>, the initiating party demands authentication; the accepting party <emphasis remap='I'>must</emphasis> pick an authentication scheme and use it. In this case, the only valid response is <function>AuthenticationRequired</function> </para> <para> If must-authenticate is <function>False</function>, the accepting party may choose an authentication mechanism, use a host-address-based authentication scheme, or skip authentication. When must-authenticate is <function>False</function>, <function>ProtocolReply</function> and <function>AuthenticationRequired</function> are both valid responses. If a host-address-based authentication scheme is used, <function>AuthenticationRejected</function> and <function>AuthenticationFailed</function> errors are possible. </para> <para> Authentication-protocol-names specifies a (possibly null, if must-authenticate is <function>False</function> list of authentication protocols the party is willing to perform. If must-authenticate is <function>True</function> presumably the party will offer only authentication mechanisms allowing mutual authentication. </para> <para><function>ProtocolReply</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>major-opcode</emphasis>:</term> <listitem> <para>CARD8</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>version-index</emphasis>:</term> <listitem> <para>CARD8</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis>:</term> <listitem> <para>STRING</para> </listitem> </varlistentry> </variablelist> <para> This message is sent in response to a <function>ProtocolSetup</function> or <function>AuthenticationReply</function> message to indicate that the authentication handshake is complete. </para> <para> Major-opcode gives the opcode that this party will use in messages that it sends. </para> <para> Version-index gives a 0-based index into the list of versions offered in the <function>ProtocolSetup</function> message; it specifies the version of the protocol that both parties should speak for the duration of the connection. </para> <para> Vendor and release are identification strings with semantics defined by the specific protocol being negotiated. </para> <para><function>Ping</function></para> <variablelist> <varlistentry> <term>Response:</term> <listitem> <para><function>PingReply</function></para> </listitem> </varlistentry> </variablelist> <para> This message is used to test if the connection is still functioning. </para> <para><function>PingReply</function></para> <para> This message is sent in response to a <function>Ping</function> message, indicating that the connection is still functioning. </para> <para><function>WantToClose</function></para> <variablelist> <varlistentry> <term>Responses:</term> <listitem> <para> <function>WantToClose</function>, <function>NoClose</function>, <function>ProtocolSetup</function> </para> </listitem> </varlistentry> </variablelist> <para> This message is used to initiate a possible close of the connection. The sending party has noticed that, as a result of mechanisms specific to each protocol, there are no active protocols left. There are four possible scenarios arising from this request: </para> <orderedlist> <listitem> <para> The receiving side noticed too, and has already sent a <function>WantToClose</function> On receiving a <function>WantToClose</function> while already attempting to shut down, each party should simply close the connection. </para> </listitem> <listitem> <para> The receiving side hasn't noticed, but agrees. It closes the connection. </para> </listitem> <listitem> <para> The receiving side has a <function>ProtocolSetup</function> "in flight," in which case it is to ignore <function>WantToClose</function> and the party sending <function>WantToClose</function> is to abandon the shutdown attempt when it receives the <function>ProtocolSetup</function> </para> </listitem> <listitem> <para> The receiving side wants the connection kept open for some reason not specified by the ICE protocol, in which case it sends <function>NoClose</function> </para> </listitem> </orderedlist> <para> See the state transition diagram for additional information. </para> <para><function>NoClose</function></para> <para> This message is sent in response to a <function>WantToClose</function> message to indicate that the responding party does not want the connection closed at this time. The receiving party should not close the connection. Either party may again initiate <function>WantToClose</function> at some future time. </para> <sect1 id='Generic_Error_Classes'> <title>Generic Error Classes</title> <para> These errors should be used by all protocols, as applicable. For ICE (major opcode 0), <function>FatalToProtocol</function> should be interpreted as <function>FatalToConnection</function>. </para> <para><function>BadMinor</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><any></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> <function>FatalToProtocol</function> or <function>CanContinue</function> (protocol's discretion) </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>(none)</para> </listitem> </varlistentry> </variablelist> <para> Received a message with an unknown minor opcode. </para> <para><function>BadState</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><any></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> <function>FatalToProtocol</function> or <function>CanContinue</function> (protocol's discretion) </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>(none)</para> </listitem> </varlistentry> </variablelist> <para> Received a message with a valid minor opcode which is not appropriate for the current state of the protocol. </para> <para><function>BadLength</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><any></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> <function>FatalToProtocol</function> or <function>CanContinue</function> (protocol's discretion) </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>(none)</para> </listitem> </varlistentry> </variablelist> <para> Received a message with a bad length. The length of the message is longer or shorter than required to contain the data. </para> <para><function>BadValue</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><any></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>CanContinue</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para> CARD32 Byte offset to offending value in offending message. CARD32 Length of offending value. <varies> Offending value </para> </listitem> </varlistentry> </variablelist> <para>Received a message with a bad value specified.</para> </sect1> <sect1 id='ICE_Error_Classes'> <title>ICE Error Classes</title> <para>These errors are all major opcode 0 errors.</para> <para><function>BadMajor</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><any></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>CanContinue</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>CARD8 Opcode</para> </listitem> </varlistentry> </variablelist> <para>The opcode given is not one that has been registered.</para> <para><function>NoAuthentication</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para> <function>ConnectionSetup</function>, <function>ProtocolSetup</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> <function>ConnectionSetup</function> \(-> <function>FatalToConnection</function> <function>ProtocolSetup</function> \(-> <function>FatalToProtocol</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>(none)</para> </listitem> </varlistentry> </variablelist> <para>None of the authentication protocols offered are available.</para> <para><function>NoVersion</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para> <function>ConnectionSetup</function>, <function>ProtocolSetup</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> <function>ConnectionSetup</function> \(-> <function>FatalToConnection</function> <function>ProtocolSetup</function> \(-> <function>FatalToProtocol</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>(none)</para> </listitem> </varlistentry> </variablelist> <para>None of the protocol versions offered are available.</para> <para><function>SetupFailed</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para> <function>ConnectionSetup</function>, <function>ProtocolSetup</function>, <function>AuthenticationReply</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para> <function>ConnectionSetup</function> \(-> <function>FatalToConnection</function> <function>ProtocolSetup</function> \(-> <function>FatalToProtocol</function> <function>AuthenticationReply</function> \(-> <function>FatalToConnection</function> if authenticating a connection, otherwise <function>FatalToProtocol</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>STRING reason</para> </listitem> </varlistentry> </variablelist> <para> The sending side is unable to accept the new connection or new protocol for a reason other than authentication failure. Typically this error will be a result of inability to allocate additional resources on the sending side. The reason field will give a human-interpretable message providing further detail on the type of failure. </para> <para><function>AuthenticationRejected</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para> <function>AuthenticationReply</function>, <function>AuthenticationRequired</function>, <function>AuthenticationNextPhase</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>FatalToProtocol</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>STRING reason</para> </listitem> </varlistentry> </variablelist> <para> Authentication rejected. The peer has failed to properly authenticate itself. The reason field will give a human-interpretable message providing further detail. </para> <para><function>AuthenticationFailed</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para> <function>AuthenticationReply</function>, <function>AuthenticationRequired</function>, <function>AuthenticationNextPhase</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>FatalToProtocol</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>STRING reason</para> </listitem> </varlistentry> </variablelist> <para> Authentication failed. <function>AuthenticationFailed</function> does not imply that the authentication was rejected, as <function>AuthenticationRejected</function> does. Instead it means that the sender was unable to complete the authentication for some other reason. (For instance, it may have been unable to contact an authentication server.) The reason field will give a human-interpretable message providing further detail. </para> <para><function>ProtocolDuplicate</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><function>ProtocolSetup</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>FatalToProtocol</function> (but see note)</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>STRING protocol name</para> </listitem> </varlistentry> </variablelist> <para> The protocol name was already registered. This is fatal to the "new" protocol being set up by <function>ProtocolSetup</function> but it does not affect the existing registration. </para> <para><function>MajorOpcodeDuplicate</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><function>ProtocolSetup</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>FatalToProtocol</function> (but see note)</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>CARD8 opcode</para> </listitem> </varlistentry> </variablelist> <para> The major opcode specified was already registered. This is fatal to the <quote>new</quote> protocol being set up by <function>ProtocolSetup</function> but it does not affect the existing registration. </para> <para><function>UnknownProtocol</function></para> <variablelist> <varlistentry> <term><emphasis remap='I'>offending-minor-opcode</emphasis>:</term> <listitem> <para><function>ProtocolSetup</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis>:</term> <listitem> <para><function>FatalToProtocol</function></para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis>:</term> <listitem> <para>STRING protocol name</para> </listitem> </varlistentry> </variablelist> <para>The protocol specified is not supported.</para> </sect1> </chapter> <chapter id='State_Diagrams'> <title>State Diagrams</title> <para> Here are the state diagrams for the party that initiates the connection: </para> <literallayout> <emphasis remap='C'>start</emphasis>: connect to other end, send <function>ByteOrder</function> <function>ConnectionSetup</function> -> <emphasis remap='C'>conn_wait</emphasis> <emphasis remap='C'>conn_wait</emphasis>: receive <function>ConnectionReply</function> -> <emphasis remap='C'>stasis</emphasis> receive <function>AuthenticationRequired</function> -> <emphasis remap='C'>conn_auth1</emphasis> receive <function>Error</function> -> <emphasis remap='C'>quit</emphasis> receive <other>, send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> <emphasis remap='C'>conn_auth1</emphasis>: if good auth data, send <function>AuthenticationReply</function> -> <emphasis remap='C'>conn_auth2</emphasis> if bad auth data, send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> <emphasis remap='C'>conn_auth2</emphasis>: receive <function>ConnectionReply</function> -> <emphasis remap='C'>stasis</emphasis> receive <function>AuthenticationNextPhase</function> -> <emphasis remap='C'>conn_auth1</emphasis> receive <function>Error</function> -> <emphasis remap='C'>quit</emphasis> receive <other>, send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> </literallayout> <para> Here are top-level state transitions for the party that accepts connections. </para> <literallayout> <emphasis remap='C'>listener</emphasis>: accept connection -> <emphasis remap='C'>init_wait</emphasis> <emphasis remap='C'>init_wait</emphasis>: receive <function>ByteOrder</function> <function>ConnectionSetup</function> -> <emphasis remap='C'>auth_ask</emphasis> receive <other>, send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> <emphasis remap='C'>auth_ask</emphasis>: send <function>ByteOrder</function> <function>ConnectionReply</function> -> <emphasis remap='C'>stasis</emphasis> send <function>AuthenticationRequired</function> -> <emphasis remap='C'>auth_wait</emphasis> send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> <emphasis remap='C'>auth_wait</emphasis>: receive <function>AuthenticationReply</function> -> <emphasis remap='C'>auth_check</emphasis> receive <other>, send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> <emphasis remap='C'>auth_check</emphasis>: if no more auth needed, send <function>ConnectionReply</function> -> <emphasis remap='C'>stasis</emphasis> if good auth data, send <function>AuthenticationNextPhase</function> -> <emphasis remap='C'>auth_wait</emphasis> if bad auth data, send <function>Error</function> -> <emphasis remap='C'>quit</emphasis> </literallayout> <para> Here are the top-level state transitions for all parties after the initial connection establishment subprotocol. </para> <note> <para> Note: this is not quite the truth for branches out from stasis, in that multiple conversations can be interleaved on the connection. </para> </note> <literallayout> <emphasis remap='C'>stasis</emphasis>: send <function>ProtocolSetup</function> -> <emphasis remap='C'>proto_wait</emphasis> receive <function>ProtocolSetup</function> -> <emphasis remap='C'>proto_reply</emphasis> send <function>Ping</function> -> <emphasis remap='C'>ping_wait</emphasis> receive <function>Ping</function> send <function>PingReply</function> -> <emphasis remap='C'>stasis</emphasis> receive <function>WantToClose</function> -> <emphasis remap='C'>shutdown_attempt</emphasis> receive <other>, send <function>Error</function> -> <emphasis remap='C'>stasis</emphasis> all protocols shut down, send <function>WantToClose</function> -> <emphasis remap='C'>close_wait</emphasis> <emphasis remap='C'>proto_wait</emphasis>: receive <function>ProtocolReply</function> -> <emphasis remap='C'>stasis</emphasis> receive <function>AuthenticationRequired</function> -> <emphasis remap='C'>give_auth1</emphasis> receive <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> receive <function>WantToClose</function> -> <emphasis remap='C'>proto_wait</emphasis> <emphasis remap='C'>give_auth1</emphasis>: if good auth data, send <function>AuthenticationReply</function> -> <emphasis remap='C'>give_auth2</emphasis> if bad auth data, send <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> receive <function>WantToClose</function> -> <emphasis remap='C'>give_auth1</emphasis> <emphasis remap='C'>give_auth2</emphasis>: receive <function>ProtocolReply</function> -> <emphasis remap='C'>stasis</emphasis> receive <function>AuthenticationNextPhase</function> -> <emphasis remap='C'>give_auth1</emphasis> receive <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> receive <function>WantToClose</function> -> <emphasis remap='C'>give_auth2</emphasis> <emphasis remap='C'>proto_reply</emphasis>: send <function>ProtocolReply</function> -> <emphasis remap='C'>stasis</emphasis> send <function>AuthenticationRequired</function> -> <emphasis remap='C'>take_auth1</emphasis> send <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> <emphasis remap='C'>take_auth1</emphasis>: receive <function>AuthenticationReply</function> -> <emphasis remap='C'>take_auth2</emphasis> receive <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> <emphasis remap='C'>take_auth2</emphasis>: if good auth data \(-> <emphasis remap='C'>take_auth3</emphasis> if bad auth data, send <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> <emphasis remap='C'>take_auth3</emphasis>: if no more auth needed, send <function>ProtocolReply</function> -> <emphasis remap='C'>stasis</emphasis> if good auth data, send <function>AuthenticationNextPhase</function> -> <emphasis remap='C'>take_auth1</emphasis> if bad auth data, send <function>Error</function> give up on this protocol -> <emphasis remap='C'>stasis</emphasis> <emphasis remap='C'>ping_wait</emphasis>: receive <function>PingReply</function> -> <emphasis remap='C'>stasis</emphasis> <emphasis remap='C'>quit</emphasis>: -> close connection </literallayout> <para> Here are the state transitions for shutting down the connection: </para> <literallayout> <emphasis remap='C'>shutdown_attempt</emphasis>: if want to stay alive anyway, send <function>NoClose</function> -> <emphasis remap='C'>stasis</emphasis> else -> <emphasis remap='C'>quit</emphasis> <emphasis remap='C'>close_wait</emphasis>: receive <function>ProtocolSetup</function> -> <emphasis remap='C'>proto_reply</emphasis> receive <function>NoClose</function> -> <emphasis remap='C'>stasis</emphasis> receive <function>WantToClose</function> -> <emphasis remap='C'>quit</emphasis> connection close -> <emphasis remap='C'>quit</emphasis> </literallayout> </chapter> <chapter id='Protocol_Encoding'> <title>Protocol Encoding</title> <para> In the encodings below, the first column is the number of bytes occupied. The second column is either the type (if the value is variable) or the actual value. The third column is the description of the value (e.g., the parameter name). Receivers must ignore bytes that are designated as unused or pad bytes. </para> <para> This document describes major version 1, minor version 0 of the ICE protocol. </para> <para> LISTof<type> indicates some number of repetitions of <type>, with no additional padding. The number of repetitions must be specified elsewhere in the message. </para> <sect1 id='Primitives'> <title>Primitives</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='3' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='1.0*'/> <colspec colname='c3' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Type Name</entry> <entry>Length (bytes)</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry>CARD8</entry> <entry>1</entry> <entry>8-bit unsigned integer</entry> </row> <row> <entry>CARD16</entry> <entry>2</entry> <entry>16-bit unsigned integer</entry> </row> <row> <entry>CARD32</entry> <entry>4</entry> <entry>32-bit unsigned integer</entry> </row> <row> <entry>LPCE</entry> <entry>1</entry> <entry><para>A character from the X Portable Character Set in Latin Portable Character Encoding</para></entry> </row> </tbody> </tgroup> </informaltable> </sect1> <sect1 id='Enumerations'> <title>Enumerations</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='3' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='1.0*'/> <colspec colname='c3' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Type Name</entry> <entry>Value</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry>BOOL</entry> <entry>0</entry> <entry>False</entry> </row> <row> <entry></entry> <entry>1</entry> <entry>True</entry> </row> </tbody> </tgroup> </informaltable> </sect1> <sect1 id='Compound_Types'> <title>Compound Types</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='4' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='1.0*'/> <colspec colname='c3' colwidth='1.0*'/> <colspec colname='c4' colwidth='2.0*'/> <thead> <row rowsep='1'> <entry>Type Name</entry> <entry>Length (bytes)</entry> <entry>Type</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry>VERSION</entry> <entry></entry> <entry></entry> <entry></entry> </row> <row> <entry></entry> <entry>2</entry> <entry>CARD16</entry> <entry>Major version number</entry> </row> <row> <entry></entry> <entry>2</entry> <entry>CARD16</entry> <entry>Minor version number</entry> </row> <row> <entry>STRING</entry> <entry></entry> <entry></entry> <entry></entry> </row> <row> <entry></entry> <entry>2</entry> <entry>CARD16</entry> <entry>length of string in bytes</entry> </row> <row> <entry></entry> <entry>n</entry> <entry>LISTofLPCE</entry> <entry>string</entry> </row> <row> <entry></entry> <entry>p</entry> <entry></entry> <entry>unused, p = pad(n+2, 4)</entry> </row> </tbody> </tgroup> </informaltable> </sect1> <sect1 id='ICE_Minor_opcodes'> <title>ICE Minor opcodes</title> <informaltable frame='topbot'> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='1.0*'/> <thead> <row rowsep='1'> <entry>Message Name</entry> <entry>Encoding</entry> </row> </thead> <tbody> <row> <entry>Error</entry> <entry>0</entry> </row> <row> <entry>ByteOrder</entry> <entry>1</entry> </row> <row> <entry>ConnectionSetup</entry> <entry>2</entry> </row> <row> <entry>AuthenticationRequired</entry> <entry>3</entry> </row> <row> <entry>AuthenticationReply</entry> <entry>4</entry> </row> <row> <entry>AuthenticationNextPhase</entry> <entry>5</entry> </row> <row> <entry>ConnectionReply</entry> <entry>6</entry> </row> <row> <entry>ProtocolSetup</entry> <entry>7</entry> </row> <row> <entry>ProtocolReply</entry> <entry>8</entry> </row> <row> <entry>Ping</entry> <entry>9</entry> </row> <row> <entry>PingReply</entry> <entry>10</entry> </row> <row> <entry>WantToClose</entry> <entry>11</entry> </row> <row> <entry>NoClose</entry> <entry>12</entry> </row> </tbody> </tgroup> </informaltable> </sect1> <sect1 id='Message_Encoding'> <title>Message Encoding</title> <literallayout class="monospaced"> <function>Error</function> 1 CARD8 major-opcode 1 0 Error 2 CARD16 class 4 (n+p)/8+1 length 1 CARD8 offending-minor-opcode 1 severity: 0 CanContinue 1 FatalToProtocol 2 FatalToConnection 2 unused 4 CARD32 sequence number of erroneous message n <varies> value(s) p pad, p = pad(n,8) </literallayout> <literallayout class="monospaced"> <function>ByteOrder</function> 1 0 ICE 1 1 ByteOrder 1 byte-order: 0 LSBfirst 1 MSBfirst 1 unused 4 0 length </literallayout> <literallayout class="monospaced"> <function>ConnectionSetup</function> 1 0 ICE 1 2 ConnectionSetup 1 CARD8 Number of versions offered 1 CARD8 Number of authentication protocol names offered 4 (i+j+k+m+p)/8+1 length 1 BOOL must-authenticate 7 unused i STRING vendor j STRING release k LISTofSTRING authentication-protocol-names m LISTofVERSION version-list p unused, p = pad(i+j+k+m,8) </literallayout> <literallayout class="monospaced"> <function>AuthenticationRequired</function> 1 0 ICE 1 3 AuthenticationRequired 1 CARD8 authentication-protocol-index 1 unused 4 (n+p)/8+1 length 2 n length of authentication data 6 unused n <varies> data p unused, p = pad(n,8) </literallayout> <literallayout class="monospaced"> <function>AuthenticationReply</function> 1 0 ICE 1 4 AuthenticationReply 2 unused 4 (n+p)/8+1 length 2 n length of authentication data 6 unused n <varies> data p unused, p = pad(n,8) </literallayout> <literallayout class="monospaced"> <function>AuthenticationNextPhase</function> 1 0 ICE 1 5 AuthenticationNextPhase 2 unused 4 (n+p)/8+1 length 2 n length of authentication data 6 unused n <varies> data p unused, p = pad(n,8) </literallayout> <literallayout class="monospaced"> <function>ConnectionReply</function> 1 0 ICE 1 6 ConnectionReply 1 CARD8 version-index 1 unused 4 (i+j+p)/8 length i STRING vendor j STRING release p unused, p = pad(i+j,8) </literallayout> <literallayout class="monospaced"> <function>ProtocolSetup</function> 1 0 ICE 1 7 ProtocolSetup 1 CARD8 major-opcode 1 BOOL must-authenticate 4 (i+j+k+m+n+p)/8+1 length 1 CARD8 Number of versions offered 1 CARD8 Number of authentication protocol names offered 6 unused i STRING protocol-name j STRING vendor k STRING release m LISTofSTRING authentication-protocol-names n LISTofVERSION version-list p unused, p = pad(i+j+k+m+n,8) </literallayout> <literallayout class="monospaced"> <function>ProtocolReply</function> 1 0 ICE 1 8 ProtocolReply 1 CARD8 version-index 1 CARD8 major-opcode 4 (i+j+p)/8 length i STRING vendor j STRING release p unused, p = pad(i+j, 8) </literallayout> <literallayout class="monospaced"> <function>Ping</function> 1 0 ICE 1 9 Ping 2 0 unused 4 0 length </literallayout> <literallayout class="monospaced"> <function>PingReply</function> 1 0 ICE 1 10 PingReply 2 0 unused 4 0 length </literallayout> <literallayout class="monospaced"> <function>WantToClose</function> 1 0 ICE 1 11 WantToClose 2 0 unused 4 0 length </literallayout> <literallayout class="monospaced"> <function>NoClose</function> 1 0 ICE 1 12 NoClose 2 0 unused 4 0 length </literallayout> </sect1> <sect1 id='Error_Class_Encoding'> <title>Error Class Encoding</title> <para> Generic errors have classes in the range 0x8000-0xFFFF, and subprotocol-specific errors are in the range 0x0000-0x7FFF. </para> <sect2 id='Generic_Error_Class_Encoding'> <title>Generic Error Class Encoding</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Class</entry> <entry>Encoding</entry> </row> </thead> <tbody> <row> <entry>BadMinor</entry> <entry>0x8000</entry> </row> <row> <entry>BadState</entry> <entry>0x8001</entry> </row> <row> <entry>BadLength</entry> <entry>0x8002</entry> </row> <row> <entry>BadValue</entry> <entry>0x8003</entry> </row> </tbody> </tgroup> </informaltable> </sect2> <sect2 id='ICE_specific_Error_Class_Encoding'> <title>ICE-specific Error Class Encoding</title> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Class</entry> <entry>Encoding</entry> </row> </thead> <tbody> <row> <entry>BadMajor</entry> <entry>0</entry> </row> <row> <entry>NoAuthentication</entry> <entry>1</entry> </row> <row> <entry>NoVersion</entry> <entry>2</entry> </row> <row> <entry>SetupFailed</entry> <entry>3</entry> </row> <row> <entry>AuthenticationRejected</entry> <entry>4</entry> </row> <row> <entry>AuthenticationFailed</entry> <entry>5</entry> </row> <row> <entry>ProtocolDuplicate</entry> <entry>6</entry> </row> <row> <entry>MajorOpcodeDuplicate</entry> <entry>7</entry> </row> <row> <entry>UnknownProtocol</entry> <entry>8</entry> </row> </tbody> </tgroup> </informaltable> </sect2> </sect1> </chapter> <appendix id="modification_history"> <title>Modification History</title> <sect1 id='Release_6_to_Release_61_1'> <title>Release 6 to Release 6.1</title> <para> Release 6.1 added the ICE X rendezvous protocol (Appendix B) and updated the document version to 1.1. </para> </sect1> <sect1 id='Release_61_to_Release_63_3'> <title>Release 6.1 to Release 6.3</title> <para>Release 6.3 added the listen on well known ports feature.</para> </sect1> </appendix> <appendix id="ice_x_rendezvous_protocol"> <title>ICE X Rendezvous Protocol</title> <sect1 id='Introduction'> <title>Introduction</title> <para> The ICE X rendezvous protocol is designed to answer the need posed in Section 2 for one mechanism by which two clients interested in communicating via ICE are able to exchange the necessary information. This protocol is appropriate for any two ICE clients who also have X connections to the same X server. </para> </sect1> <sect1 id='Overview_of_ICE_X_Rendezvous'> <title>Overview of ICE X Rendezvous</title> <para> The ICE X Rendezvous Mechanism requires clients willing to act as ICE originating parties to pre-register the ICE subprotocols they support in an ICE_PROTOCOLS property on their top-level window. Clients willing to act as ICE answering parties then send an ICE_PROTOCOLS X <function>ClientMessage</function> event to the ICE originating parties. This <function>ClientMessage</function> event identifies the ICE network IDs of the ICE answering party as well as the ICE subprotocol it wishes to speak. Upon receipt of this message the ICE originating party uses the information to establish an ICE connection with the ICE answering party. </para> </sect1> <sect1 id='Registering_Known_Protocols'> <title>Registering Known Protocols</title> <para> Clients willing to act as ICE originating parties preregister the ICE subprotocols they support in a list of atoms held by an ICE_PROTOCOLS property on their top-level window. The name of each atom listed in ICE_PROTOCOLS must be of the form ICE_INITIATE_<emphasis remap='I'>pname</emphasis> where <emphasis remap='I'>pname</emphasis> is the name of the ICE subprotocol the ICE originating party is willing to speak, as would be specified in an ICE <function>ProtocolSetup</function> message. </para> <para> Clients with an ICE_INITIATE_<emphasis remap='I'>pname</emphasis> atom in the ICE_PROTOCOLS property on their top-level windows must respond to <function>ClientMessage</function> events of type ICE_PROTOCOLS specifying ICE_INITIATE_ <emphasis remap='I'>pname</emphasis>. If a client does not want to respond to these client message events, it should remove the ICE_INITIATE_<emphasis remap='I'>pname</emphasis> atom from its ICE_PROTOCOLS property or remove the ICE_PROTOCOLS property entirely. </para> </sect1> <sect1 id='Initiating_the_Rendezvous'> <title>Initiating the Rendezvous</title> <para> To initiate the rendezvous a client acting as an ICE answering party sends an X <function>ClientMessage</function> event of type ICE_PROTOCOLS to an ICE originating party. This ICE_PROTOCOLS client message contains the information the ICE originating party needs to identify the ICE subprotocol the two parties will use as well as the ICE network identification string of the ICE answering party. </para> <para> Before the ICE answering party sends the client message event it must define a text property on one of its windows. This text property contains the ICE answering party's ICE network identification string and will be used by ICE originating parties to determine the ICE answering party's list of ICE network IDs. </para> <para> The property name will normally be ICE_NETWORK_IDS, but may be any name of the ICE answering party's choosing. The format for this text property is as follows: </para> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Field</entry> <entry>Value</entry> </row> </thead> <tbody> <row> <entry>type</entry> <entry>XA_STRING</entry> </row> <row> <entry>format</entry> <entry>8</entry> </row> <row> <entry>value</entry> <entry>comma-separated list of ICE network IDs</entry> </row> </tbody> </tgroup> </informaltable> <para> Once the ICE answering party has established this text property on one of its windows, it initiates the rendezvous by sending an ICE_PROTOCOLS <function>ClientMessage</function> event to an ICE originating party's top-level window. This event has the following format and must only be sent to windows that have pre-registered the ICE subprotocol in an ICE_PROTOCOLS property on their top-level window. </para> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Field</entry> <entry>Value</entry> </row> </thead> <tbody> <row> <entry>message_type</entry> <entry>Atom = "ICE_PROTOCOLS"</entry> </row> <row> <entry>format</entry> <entry>32</entry> </row> <row> <entry>data.l[0]</entry> <entry>Atom identifying the ICE subprotocol to speak</entry> </row> <row> <entry>data.l[1]</entry> <entry>Timestamp</entry> </row> <row> <entry>data.l[2]</entry> <entry><para>ICE answering party's window ID with ICE network IDs text property</para></entry> </row> <row> <entry>data.l[3]</entry> <entry>Atom naming text property containing the ICE answering party's ICE network IDs</entry> </row> <row> <entry>data.l[4]</entry> <entry>Reserved. Must be 0.</entry> </row> </tbody> </tgroup> </informaltable> <para> The name of the atom in data.l[0] must be of the form ICE_INITIATE_<emphasis remap='I'>pname</emphasis>, where <emphasis remap='I'>pname</emphasis> is the name of the ICE subprotocol the ICE answering party wishes to speak. </para> <para> When an ICE originating party receives a <function>ClientMessage</function> event of type ICE_PROTOCOLS specifying ICE_INITIATE_<emphasis remap='I'>pname</emphasis> it can initiate an ICE connection with the ICE answering party. To open this connection the client retrieves the ICE answering party's ICE network IDs from the window specified in data.l[2] using the text property specified in data.l[3]. </para> <para> If the connection attempt fails for any reason, the client must respond to the client message event by sending a return <function>ClientMessage</function> event to the window specified in data.l[2]. This return event has the following format: </para> <informaltable frame='topbot'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Field</entry> <entry>Value</entry> </row> </thead> <tbody> <row> <entry>message_type</entry> <entry>Atom = "ICE_INITIATE_FAILED"</entry> </row> <row> <entry>format</entry> <entry>32</entry> </row> <row> <entry>data.l[0]</entry> <entry>Atom identifying the ICE subprotocol requested</entry> </row> <row> <entry>data.l[1]</entry> <entry>Timestamp</entry> </row> <row> <entry>data.l[2]</entry> <entry><para>Initiating party's window ID (holding ICE_PROTOCOLS)</para></entry> </row> <row> <entry>data.l[3]</entry> <entry>int: reason for failure</entry> </row> <row> <entry>data.l[4]</entry> <entry>Reserved, must be 0</entry> </row> </tbody> </tgroup> </informaltable> <para> The values of data.l[0] and data.l[1] are copied directly from the client message event the client received. </para> <para> The value in data.l[2] is the id of the window to which the ICE_PROTOCOLS.ICE_INITIATE_<emphasis remap='I'>pname</emphasis> client message event was sent. </para> <para>Data.l[3] has one of the following values:</para> <!-- .ne 21 --> <informaltable frame='topbot'> <tgroup cols='3' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.5*'/> <colspec colname='c2' colwidth='1.0*'/> <colspec colname='c3' colwidth='3.0*'/> <thead> <row rowsep='1'> <entry>Value</entry> <entry>Encoding</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry>OpenFailed</entry> <entry>1</entry> <entry> The client was unable to open the connection (e.g. a call to IceOpenConnection() failed). If the client is able to distinguish authentication or authorization errors from general errors, then the preferred reply is <function>AuthenticationFailed</function> for authorization errors. </entry> </row> <row> <entry>AuthenticationFailed</entry> <entry>2</entry> <entry>Authentication or authorization of the connection or protocol setup was refused. This reply will be given only if the client is able to distinguish it from <function>OpenFailed</function> otherwise <function>OpenFailed</function> will be returned.</entry> </row> <row> <entry>SetupFailed</entry> <entry>3</entry> <entry>The client was unable to initiate the specified protocol on the connection (e.g. a call to IceProtocolSetup() failed).</entry> </row> <row> <entry>UnknownProtocol</entry> <entry>4</entry> <entry>The client does not recognize the requested protocol. (This represents a semantic error on the part of the answering party.)</entry> </row> <row> <entry>Refused</entry> <entry>5</entry> <entry> The client was in the process of removing ICE_INITIATE_<emphasis remap='I'>pname</emphasis> from its ICE_PROTOCOLS list when the client message was sent; the client no longer is willing to establish the specified ICE communication.</entry> </row> </tbody> </tgroup> </informaltable> <note> <para> Clients willing to act as ICE originating parties must update the ICE_PROTOCOLS property on their top-level windows to include the ICE_INITIATE_<emphasis remap='I'>pname</emphasis> atom(s) identifying the ICE subprotocols they speak. The method a client uses to update the ICE_PROTOCOLS property to include ICE_INITIATE_<emphasis remap='I'>pname</emphasis> atoms is implementation dependent, but the client must ensure the integrity of the list to prevent the accidental omission of any atoms previously in the list. </para> <para> When setting up the ICE network IDs text property on one of its windows, the ICE answering party can determine its comma-separated list of ICE network IDs by calling IceComposeNetworkIdList() after making a call to IceListenForConnections(). The method an ICE answering party uses to find the top-level windows of clients willing to act as ICE originating parties is dependent upon the nature of the answering party. Some may wish to use the approach of requiring the user to click on a client's window. Others wishing to find existing clients without requiring user interaction might use something similar to the XQueryTree() method used by several freely-available applications. In order for the ICE answering party to become automatically aware of new clients willing to originate ICE connections, the ICE answering party might register for SubstructureNotify events on the root window of the display. When it receives a SubstructureNotify event, the ICE answering party can check to see if it was the result of the creation of a new client top-level window with an ICE_PROTOCOLS property. </para> <para> In any case, before attempting to use this ICE X Rendezvous Mechanism ICE answering parties wishing to speak ICE subprotocol <emphasis remap='I'>pname</emphasis> should check for the ICE_INITIATE_<emphasis remap='I'>pname</emphasis> atom in the ICE_PROTOCOLS property on a client's top-level window. A client that does not include an ICE_INITIATE_<emphasis remap='I'>pname</emphasis> atom in a ICE_PROTOCOLS property on some top-level window should be assumed to ignore <function>ClientMessage</function> events of type ICE_PROTOCOLS specifying ICE_INITIATE_<emphasis remap='I'>pname</emphasis> for ICE subprotocol <emphasis remap='I'>pname</emphasis>. </para> </note> </sect1> <sect1 id='ICE_Subprotocol_Versioning'> <title>ICE Subprotocol Versioning</title> <para> Although the version of the ICE subprotocol could be passed in the client message event, ICE provides more a flexible version negotiation mechanism than will fit within a single <function>ClientMessage</function> event. Because of this, ICE subprotocol versioning is handled within the ICE protocol setup phase.</para> <note remap='NT'> <para>Clients wish to communicate with each other via an ICE subprotocol known as "RAP V1.0". In RAP terminology one party, the "agent", communicates with other RAP-enabled applications on demand. The user may direct the agent to establish communication with a specific application by clicking on the application's window, or the agent may watch for new application windows to be created and automatically establish communication. </para> <para> During startup the ICE answering party (the agent) first calls IceRegisterForProtocolReply() with a list of the versions (i.e., 1.0) of RAP the agent can speak. The answering party then calls IceListenForConnections() followed by IceComposeNetworkIdList() and stores the resulting ICE network IDs string in a text property on one of its windows. </para> <para> When the answering party (agent) finds a client with which it wishes to speak, it checks to see if the ICE_INITIATE_RAP atom is in the ICE_PROTOCOLS property on the client's top-level window. If it is present the agent sends the client's top-level window an ICE_PROTOCOLS client message event as described above. When the client receives the client message event and is willing to originate an ICE connection using RAP, it performs an IceRegisterForProtocolSetup() with a list of the versions of RAP the client can speak. The client then retrieves the agent's ICE network ID from the property and window specified by the agent in the client message event and calls IceOpenConnection(). After this call succeeds the client calls IceProtocolSetup() specifying the RAP protocol. During this process, ICE calls the RAP protocol routines that handle the version negotiation. </para> <para> Note that it is not necessary for purposes of this rendezvous that the client application call any ICElib functions prior to receipt of the client message event. </para> </note> </sect1> </appendix> </book> PK t��[ƚ�� � AUTHORSnu �[��� Ralph Mor, of the X Consortium is the original author. OS/2 support, Holger Veit, bug fixes by Keith Packard, Petter Reinholdtsen, others. Our apologies if we've overlooked a contributor. PK t��[�C�e� � COPYINGnu �[��� Copyright 1993, 1998 The Open Group Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. 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, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 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 Open Group 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 Open Group. Author: Ralph Mor, X Consortium PK t��[,�p|C |C ICElib.xmlnu �[��� <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ <!ENTITY % defs SYSTEM "defs.ent"> %defs; ]> <book id="ICElib"> <bookinfo> <title>Inter-Client Exchange Library</title> <subtitle>X Consortium Standard</subtitle> <releaseinfo>X Version 11, Release &fullrelvers;</releaseinfo> <releaseinfo>Version 1.0</releaseinfo> <authorgroup> <author> <firstname>Ralph</firstname><surname>Mor</surname> <affiliation><orgname>X Consortium</orgname></affiliation> </author> </authorgroup> <copyright> <year>1993</year><year>1994</year><year>1996</year> <holder>X Consortium</holder> </copyright> <legalnotice> <para> 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 Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: </para> <para>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. </para> <para> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 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. </para> <para> 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. </para> </legalnotice> </bookinfo> <chapter id='Overview_of_ICE'> <title>Overview of ICE</title> <para> There are numerous possible inter-client protocols, with many similarities and common needs - authentication, version negotiation, byte order negotiation, and so on. The Inter-Client Exchange (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. </para> </chapter> <chapter id='The_ICE_Library___C_Language_Interface_to_ICE'> <title>The ICE Library - C Language Interface to ICE</title> <para> 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 either to 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 <function>ProtocolSetup</function> in order to "activate" a given protocol. Once the other client accepts the <function>ProtocolSetup</function> (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 subprotocol triggers a protocol shutdown. </para> <para> The ICE library utilizes callbacks to process incoming messages. Using callbacks allows <function>ProtocolSetup</function> messages 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. </para> </chapter> <chapter id='Intended_Audience'> <title>Intended Audience</title> <para>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.</para> </chapter> <chapter id='Header_Files_and_Library_Name'> <title>Header Files and Library Name</title> <para>The header file <<symbol role='Pn'>X11/ICE/ICElib.h</symbol>> defines all of the ICElib data structures and function prototypes. <function>ICElib.h</function> includes the header file <<symbol role='Pn'>X11/ICE/ICE.h</symbol>>, which defines all of the ICElib constants. Protocol libraries that need to read and write messages should include the header file <<symbol role='Pn'>X11/ICE/ICEmsg.h</symbol>>.</para> <para>Applications should link against ICElib using -lICE.</para> </chapter> <chapter id='Note_on_Prefixes'> <title>Note on Prefixes</title> <para>The following name prefixes are used in the library to distinguish between a client that initiates a <function>ProtocolSetup</function> and a client that responds with a <function>ProtocolReply</function></para> <itemizedlist> <listitem> <para><function>IcePo</function> - Ice Protocol Originator</para> </listitem> <listitem> <para><function>IcePa</function> - Ice Protocol Acceptor</para> </listitem> </itemizedlist> </chapter> <chapter id='Protocol_Registration'> <title>Protocol Registration</title> <para> 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: </para> <itemizedlist> <listitem> <para> One to handle the side that does a <function>ProtocolSetup</function> </para> </listitem> <listitem> <para> One to handle the side that responds with a <function>ProtocolReply</function> </para> </listitem> </itemizedlist> <para> 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 <function>ProtocolSetup</function> is received, but the protocol is not registered. If it is not possible to register a protocol before the creation of an ICE connection, proper precautions should be taken to avoid the above race condition. </para> <para> The <xref linkend='IceRegisterForProtocolSetup' xrefstyle='select: title'/> function should be called for the client that initiates a <function>ProtocolSetup</function> </para> <funcsynopsis id='IceRegisterForProtocolSetup'> <funcprototype> <funcdef>int <function>IceRegisterForProtocolSetup</function></funcdef> <paramdef>const char<parameter> *protocol_name</parameter></paramdef> <paramdef>const char<parameter> *vendor</parameter></paramdef> <paramdef>const char<parameter> *release</parameter></paramdef> <paramdef>int<parameter> version_count</parameter></paramdef> <paramdef>IcePoVersionRec<parameter> *version_recs</parameter></paramdef> <paramdef>int<parameter> auth_count</parameter></paramdef> <paramdef>char<parameter> **auth_names</parameter></paramdef> <paramdef>IcePoAuthProc<parameter> *auth_procs</parameter></paramdef> <paramdef>IceIOErrorProc<parameter> io_error_proc</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>protocol_name</emphasis></term> <listitem> <para> A string specifying the name of the protocol to register. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis></term> <listitem> <para>A vendor string with semantics specified by the protocol.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis></term> <listitem> <para>A release string with semantics specified by the protocol.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>version_count</emphasis></term> <listitem> <para>The number of different versions of the protocol supported.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>version_recs</emphasis></term> <listitem> <para>List of versions and associated callbacks.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_count</emphasis></term> <listitem> <para>The number of authentication methods supported.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_names</emphasis></term> <listitem> <para>The list of authentication methods supported.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_procs</emphasis></term> <listitem> <para> The list of authentication callbacks, one for each authentication method. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>io_error_proc</emphasis></term> <listitem> <para>IO error handler, or NULL.</para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceRegisterForProtocolSetup' xrefstyle='select: title'/> returns the major opcode reserved or -1 if an error occurred. In order to actually activate the protocol, the <xref linkend='IceProtocolSetup' xrefstyle='select: title'/> 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. </para> <para> A protocol library may support multiple versions of the same protocol. The version_recs argument specifies a list of supported versions of the protocol, which are 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. </para> <literallayout remap='Ds'> typedef struct { int major_version; int minor_version; IcePoProcessMsgProc process_msg_proc; } IcePoVersionRec; </literallayout> <para>The <function>IcePoProcessMsgProc</function> callback is responsible for processing the set of messages that can be received by the client that initiated the <function>ProtocolSetup</function> For further information, see <xref linkend='Callbacks_for_Processing_Messages' xrefstyle='select: title'/> </para> <para>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. The auth_names and auth_procs arguments are a list of authentication names and callbacks that are prioritized in decreasing order of preference. For information on the <function>IcePoAuthProc</function> callback, see <xref linkend='Authentication_Methods' xrefstyle='select: title'/> </para> <para>The <xref linkend='IceIOErrorProc' xrefstyle='select: title'/> callback is invoked if the ICE connection unexpectedly breaks. You should pass NULL for io_error_proc if not interested in being notified. For further information, <xref linkend='Error_Handling' xrefstyle='select: title'/> </para> <para>The <xref linkend='IceRegisterForProtocolReply' xrefstyle='select: title'/> function should be called for the client that responds to a <function>ProtocolSetup</function> with a <function>ProtocolReply</function></para> <funcsynopsis id='IceRegisterForProtocolReply'> <funcprototype> <funcdef>Bool <function>IceRegisterForProtocolReply</function></funcdef> <paramdef>const char<parameter> *protocol_name</parameter></paramdef> <paramdef>const char<parameter> *vendor</parameter></paramdef> <paramdef>const char<parameter> *release</parameter></paramdef> <paramdef>int<parameter> version_count</parameter></paramdef> <paramdef>IcePoVersionRec<parameter> *version_recs</parameter></paramdef> <paramdef>int<parameter> auth_count</parameter></paramdef> <paramdef>const char<parameter> **auth_names</parameter></paramdef> <paramdef>IcePoAuthProc<parameter> *auth_procs</parameter></paramdef> <paramdef>IceHostBasedAuthProc<parameter> host_based_auth_proc</parameter></paramdef> <paramdef>IceProtocolSetupProc<parameter> protocol_setup_proc</parameter></paramdef> <paramdef>IceProtocolActivateProc<parameter> protocol_activate_proc</parameter></paramdef> <paramdef>IceIOErrorProc<parameter> io_error_proc</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>protocol_name</emphasis></term> <listitem><para>A string specifying the name of the protocol to register.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis></term> <listitem> <para>A vendor string with semantics specified by the protocol.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis></term> <listitem> <para>A release string with semantics specified by the protocol.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>version_count</emphasis></term> <listitem> <para>The number of different versions of the protocol supported.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>version_recs</emphasis></term> <listitem> <para>List of versions and associated callbacks.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_count</emphasis></term> <listitem> <para>The number of authentication methods supported.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_names</emphasis></term> <listitem> <para>The list of authentication methods supported.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_procs</emphasis></term> <listitem> <para>The list of authentication callbacks, one for each authentication method.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>host_based_auth_proc</emphasis></term> <listitem> <para>Host based authentication callback.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>protocol_setup_proc</emphasis></term> <listitem> <para>A callback to be invoked when authentication has succeeded for a <function>ProtocolSetup</function> but before the <function>ProtocolReply</function> is sent.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>protocol_activate_proc</emphasis></term> <listitem> <para>A callback to be invoked after the <function>ProtocolReply</function> is sent.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>io_error_proc</emphasis></term> <listitem> <para>IO error handler, or NULL.</para> </listitem> </varlistentry> </variablelist> <para><xref linkend='IceRegisterForProtocolReply' xrefstyle='select: title'/> 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.</para> <para>A protocol library may support multiple versions of the same protocol. The version_recs argument specifies a list of supported versions of the protocol, which are 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.</para> <literallayout remap='Ds'> typedef struct { int major_version; int minor_version; IcePaProcessMsgProc process_msg_proc; } IcePaVersionRec; </literallayout> <para>The <xref linkend='IcePaProcessMsgProc' xrefstyle='select: title'/> callback is responsible for processing the set of messages that can be received by the client that accepted the <function>ProtocolSetup</function> For further information, see <xref linkend='Callbacks_for_Processing_Messages' xrefstyle='select: title'/> </para> <para>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. The auth_names and auth_procs arguments are a list of authentication names and callbacks that are prioritized in decreasing order of preference. For information on the <function>IcePaAuthProc</function>, See <xref linkend='Authentication_Methods' xrefstyle='select: title'/> </para> <para>If authentication fails and the client attempting to initiate the <function>ProtocolSetup</function> has not required authentication, the <function>IceHostBasedAuthProc</function> callback is invoked with the host name of the originating client. If the callback returns <function>True</function> the <function>ProtocolSetup</function> will succeed, even though the original authentication failed. Note that authentication can effectively be disabled by registering an <function>IceHostBasedAuthProc</function> which always returns <function>True</function> If no host based authentication is allowed, you should pass NULL for host_based_auth_proc.</para> <funcsynopsis> <funcprototype> <funcdef>Bool <function>HostBasedAuthProc</function></funcdef> <paramdef>char<parameter> *host_name</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>protocol_name</emphasis></term> <listitem><para>The host name of the client that sent the <function>ProtocolSetup</function></para></listitem> </varlistentry> </variablelist> <para>The host_name argument is a string of the form <emphasis remap='I'>protocol</emphasis>/<emphasis remap='I'>hostname</emphasis>, where <emphasis remap='I'>protocol</emphasis> is one of {tcp, decnet, local}.</para> <para>Because <function>ProtocolSetup</function> messages and authentication happen behind the scenes via callbacks, the protocol library needs some way of being notified when the <function>ProtocolSetup</function> has completed. This occurs in two phases. In the first phase, the <function>IceProtocolSetupProc</function> callback is invoked after authentication has successfully completed but before the ICE library sends a <function>ProtocolReply</function> Any resources required for this protocol should be allocated at this time. If the <function>IceProtocolSetupProc</function> returns a successful status, the ICE library will send the <function>ProtocolReply</function> and then invoke the <function>IceProtocolActivateProc</function> callback. Otherwise, an error will be sent to the other client in response to the <function>ProtocolSetup</function></para> <para>The <function>IceProtocolActivateProc</function> is an optional callback and should be registered only if the protocol library intends to generate a message immediately following the <function>ProtocolReply</function> You should pass NULL for protocol_activate_proc if not interested in this callback.</para> <funcsynopsis id='ProtocolSetupProc'> <funcprototype> <funcdef>Status <function>ProtocolSetupProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> major_version</parameter></paramdef> <paramdef>int<parameter> minor_version</parameter></paramdef> <paramdef>char<parameter> *vendor</parameter></paramdef> <paramdef>char<parameter> *release</parameter></paramdef> <paramdef>IcePointer<parameter> *client_data_ret</parameter></paramdef> <paramdef>char<parameter> **failure_reason_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>protocol_name</emphasis></term> <listitem> <para>The ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_version</emphasis></term> <listitem> <para>The major version of the protocol.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>minor_version</emphasis></term> <listitem> <para>The minor version of the protocol.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor</emphasis></term> <listitem> <para>The vendor string registered by the protocol originator.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release</emphasis></term> <listitem> <para>The release string registered by the protocol originator.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data_ret</emphasis></term> <listitem> <para>Client data to be set by callback.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>failure_reason_ret</emphasis></term> <listitem> <para>Failure reason returned.</para> </listitem> </varlistentry> </variablelist> <para>The pointer stored in the client_data_ret argument will be passed to the <xref linkend='IcePaProcessMsgProc' xrefstyle='select: title'/> callback whenever a message has arrived for this protocol on the ICE connection.</para> <para>The vendor and release strings should be freed with <function>free</function> when they are no longer needed.</para> <para>If a failure occurs, the <function>IceProtocolSetupProc</function> 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.</para> <para>The <function>IceProtocolActivateProc</function> callback is defined as follows:</para> <funcsynopsis id='ProtocolActivateProc'> <funcprototype> <funcdef>void <function>ProtocolActivateProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para> The client data set in the <function>IceProtocolSetupProc</function> callback. </para> </listitem> </varlistentry> </variablelist> <para>The <xref linkend='IceIOErrorProc' xrefstyle='select: title'/> callback is invoked if the ICE connection unexpectedly breaks. You should pass NULL for io_error_proc if not interested in being notified. For further information, see <xref linkend='Error_Handling' xrefstyle='select: title'/> </para> <sect1 id='Callbacks_for_Processing_Messages'> <title>Callbacks for Processing Messages</title> <para>When an application detects that there is new data to read on an ICE connection (via <function>select</function> it calls the <xref linkend='IceProcessMessages' xrefstyle='select: title'/> function <xref linkend='Processing_Messages' xrefstyle='select: title'/> When <xref linkend='IceProcessMessages' xrefstyle='select: title'/> reads an ICE message header with a major opcode other than zero (reserved for the ICE protocol), it needs to call a function that will read the rest of the message, unpack it, and process it accordingly.</para> <para>If the message arrives at the client that initiated the <function>ProtocolSetup</function> the <function>IcePoProcessMsgProc</function> callback is invoked.</para> <funcsynopsis id='PoProcessMsgProc'> <funcprototype> <funcdef>void <function>PoProcessMsgProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> <paramdef>int<parameter> opcode</parameter></paramdef> <paramdef>unsigned long<parameter> length</parameter></paramdef> <paramdef>Bool<parameter> swap</parameter></paramdef> <paramdef>IceReplyWaitInfo<parameter> *reply_wait</parameter></paramdef> <paramdef>Bool<parameter> *reply_ready_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para>Client data associated with this protocol on the ICE connection.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>opcode</emphasis></term> <listitem> <para>The minor opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>length</emphasis></term> <listitem> <para>The length (in 8-byte units) of the message beyond the ICE header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para>A flag that indicates if byte swapping is necessary.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_wait</emphasis></term> <listitem> <para>Indicates if the invoking client is waiting for a reply.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_ready_ret</emphasis></term> <listitem> <para>If set to <function>True</function> a reply is ready.</para> </listitem> </varlistentry> </variablelist> <para>If the message arrives at the client that accepted the <function>ProtocolSetup</function> the <xref linkend='IcePaProcessMsgProc' xrefstyle='select: title'/> callback is invoked.</para> <funcsynopsis id='IcePaProcessMsgProc'> <funcprototype> <funcdef>void <function>IcePaProcessMsgProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> <paramdef>int<parameter> opcode</parameter></paramdef> <paramdef>unsigned long<parameter> length</parameter></paramdef> <paramdef>Bool<parameter> swap</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para>Client data associated with this protocol on the ICE connection.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>opcode</emphasis></term> <listitem> <para>The minor opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>length</emphasis></term> <listitem> <para>The length (in 8-byte units) of the message beyond the ICE header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para>A flag that indicates if byte swapping is necessary.</para> </listitem> </varlistentry> </variablelist> <para>In order to read the message, both of these callbacks should use the macros defined for this purpose (see <xref linkend='Reading_ICE_Messages' xrefstyle='select: title'/>.). Note that byte swapping may be necessary. As a convenience, the length field in the ICE header will be swapped by ICElib if necessary.</para> <para>In both of these callbacks, the client_data argument is a pointer to client data that was registered at <function>ProtocolSetup</function> time. In the case of <function>IcePoProcessMsgProc</function> the client data was set in the call to <xref linkend='IceProtocolSetup' xrefstyle='select: title'/> In the case of <xref linkend='IcePaProcessMsgProc' xrefstyle='select: title'/> the client data was set in the <function>IceProtocolSetupProc</function> callback.</para> <para>The <function>IcePoProcessMsgProc</function> 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 are implementation-dependent.</para> <para>However, if reply_wait is not NULL , then the client is waiting for a reply or an error for a message it previously sent. The reply_wait is of type <function>IceReplyWaitInfo</function></para> <literallayout remap='Ds'> typedef struct { unsigned long sequence_of_request; int major_opcode_of_request; int minor_opcode_of_request; IcePointer reply; } IceReplyWaitInfo; </literallayout> <para><function>IceReplyWaitInfo</function> 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 <function>IcePointer</function> 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 <function>IcePoProcessMsgProc</function> 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 (for example., 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 <function>IcePoProcessMsgProc</function> 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.</para> <para>If reply_wait is not NULL and <function>IcePoProcessMsgProc</function> has a reply or error to return in response to this reply_wait (that is, no callback was generated), then the reply_ready_ret argument should be set to <function>True</function> Note that an error should only be returned if it corresponds to the reply being waited for. Otherwise, the <function>IcePoProcessMsgProc</function> should either handle the error internally or invoke an error handler for its library.</para> <para>If reply_wait is NULL, then care must be taken not to store any value in reply_ready_ret, because this pointer may also be NULL.</para> <para>The <xref linkend='IcePaProcessMsgProc' xrefstyle='select: title'/> 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.</para> <para>The reason the <xref linkend='IcePaProcessMsgProc' xrefstyle='select: title'/> callback does not have a reply_wait, like <function>IcePoProcessMsgProc</function> 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).</para> </sect1> <sect1 id='Authentication_Methods'> <title>Authentication Methods</title> <para>As already stated, a protocol library must register the authentication methods that it supports with the ICE library. For each authentication method, there are two callbacks that may be registered:</para> <itemizedlist> <listitem> <para> One to handle the side that initiates a <function>ProtocolSetup</function> </para> </listitem> <listitem> <para> One to handle the side that accepts or rejects this request </para> </listitem> </itemizedlist> <para><function>IcePoAuthProc</function> is the callback invoked for the client that initiated the <function>ProtocolSetup</function> This callback must be able to respond to the initial "Authentication Required" message or subsequent "Authentication Next Phase" messages sent by the other client.</para> <funcsynopsis id='IcePoAuthStatus'> <funcprototype> <funcdef>IcePoAuthStatus <function>IcePoAuthStatus </function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> <paramdef>int<parameter> opcode</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_state_ptr</emphasis></term> <listitem> <para>A pointer to state for use by the authentication callback procedure.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>clean_up</emphasis></term> <listitem> <para>If <function>True</function> authentication is over, and the function should clean up any state it was maintaining. The last 6 arguments should be ignored.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para>If <function>True</function> the auth_data may have to be byte swapped (depending on its contents).</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_datalen</emphasis></term> <listitem> <para>The length (in bytes) of the authenticator data.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_data</emphasis></term> <listitem> <para>The data from the authenticator.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_datalen_ret</emphasis></term> <listitem> <para>The length (in bytes) of the reply data returned.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_data_ret</emphasis></term> <listitem> <para>The reply data returned.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_string_ret</emphasis></term> <listitem> <para>If the authentication procedure encounters an error during authentication, it should allocate and return an error string.</para> </listitem> </varlistentry> </variablelist> <para>Authentication may require several phases, depending on the authentication method. As a result, the <function>IcePoAuthProc</function> 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 <function>ProtocolSetup</function> *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.</para> <para>If needed, the network ID of the client accepting the <function>ProtocolSetup</function> can be obtained by calling the <function>IceConnectionString</function> function.</para> <para>ICElib will be responsible for freeing the reply_data_ret and error_string_ret pointers with <function>free</function></para> <para>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.</para> <para>The <function>IcePoAuthProc</function> should return one of four values:</para> <itemizedlist> <listitem> <para><function>IcePoAuthHaveReply</function> - a reply is available.</para> </listitem> <listitem> <para><function>IcePoAuthRejected</function> - authentication rejected.</para> </listitem> <listitem> <para><function>IcePoAuthFailed</function> - authentication failed.</para> </listitem> <listitem> <para><function>IcePoAuthDoneCleanup</function> - done cleaning up.</para> </listitem> </itemizedlist> <para><function>IcePaAuthProc</function> is the callback invoked for the client that received the <function>ProtocolSetup</function></para> <funcsynopsis id='PoAuthStatus'> <funcprototype> <funcdef>IcePoAuthStatus <function>PoAuthStatus </function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> *auth_state_ptr</parameter></paramdef> <paramdef>Bool<parameter> swap</parameter></paramdef> <paramdef>int<parameter> auth_datalen</parameter></paramdef> <paramdef>IcePointer<parameter> auth_data</parameter></paramdef> <paramdef>int<parameter> *reply_datalen_ret</parameter></paramdef> <paramdef>IcePointer<parameter> *reply_data_ret</parameter></paramdef> <paramdef>char<parameter> **error_string_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_state_ptr</emphasis></term> <listitem> <para>A pointer to state for use by the authentication callback procedure.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para>If <function>True</function> auth_data may have to be byte swapped (depending on its contents).</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_datalen</emphasis></term> <listitem> <para>The length (in bytes) of the protocol originator authentication data.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_data</emphasis></term> <listitem> <para>The authentication data from the protocol originator.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_datalen_ret</emphasis></term> <listitem> <para>The length of the authentication data returned.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_data_ret</emphasis></term> <listitem> <para>The authentication data returned.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_string_ret</emphasis></term> <listitem> <para>If authentication is rejected or fails, an error string is returned.</para> </listitem> </varlistentry> </variablelist> <para>Authentication may require several phases, depending on the authentication method. As a result, the <function>IcePaAuthProc</function> 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 <function>ProtocolSetup</function> 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.</para> <para>If needed, the network ID of the client accepting the <function>ProtocolSetup</function> can be obtained by calling the <function>IceConnectionString</function> function.</para> <para>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.</para> <para>ICElib will be responsible for transmitting and freeing the reply_data_ret and error_string_ret pointers with <function>free</function></para> <para> The <function>IcePaAuthProc</function> should return one of four values: </para> <itemizedlist> <listitem> <para> <function>IcePaAuthContinue</function> - continue (or start) authentication. </para> </listitem> <listitem> <para> <function>IcePaAuthAccepted</function> - authentication accepted. </para> </listitem> <listitem> <para> <function>IcePaAuthRejected</function> - authentication rejected. </para> </listitem> <listitem> <para> <function>IcePaAuthFailed</function> - authentication failed. </para> </listitem> </itemizedlist> </sect1> </chapter> <chapter id='ICE_Connections'> <title>ICE Connections</title> <para> 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. </para> <sect1 id='Opening_an_ICE_Connection'> <title>Opening an ICE Connection</title> <para> To open an ICE connection with another client (that is, waiting for connections), use <xref linkend='IceOpenConnection' xrefstyle='select: title'/> </para> <funcsynopsis id='IceOpenConnection'> <funcprototype> <funcdef>IceConn <function>IceOpenConnection</function></funcdef> <paramdef>char<parameter> *network_ids_list</parameter></paramdef> <paramdef>IcePointer<parameter> context</parameter></paramdef> <paramdef>Bool<parameter> must_authenticate</parameter></paramdef> <paramdef>int<parameter> major_opcode_check</parameter></paramdef> <paramdef>int<parameter> error_length</parameter></paramdef> <paramdef>char<parameter> *error_string_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>network_ids_list</emphasis></term> <listitem> <para> Specifies the network ID(s) of the other client. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>context</emphasis></term> <listitem> <para> A pointer to an opaque object or NULL. Used to determine if an ICE connection can be shared (see below). </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>must_authenticate</emphasis></term> <listitem> <para> If <function>True</function> the other client may not bypass authentication. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_opcode_check</emphasis></term> <listitem> <para> Used to force a new ICE connection to be created (see below). </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_length</emphasis></term> <listitem> <para>Length of the error_string_ret argument passed in.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_string_ret</emphasis></term> <listitem> <para> Returns a null-terminated error message, if any. The error_string_ret argument points to user supplied memory. No more than error_length bytes are used. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceOpenConnection' xrefstyle='select: title'/> returns an opaque ICE connection object if it succeeds; otherwise, it returns NULL. </para> <para> The network_ids_list argument 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 following format: </para> <informaltable frame='none'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='2.0*'/> <tbody> <row> <entry>tcp/<hostname>:<portnumber></entry> <entry>or</entry> </row> <row> <entry>decnet/<hostname>::<objname></entry> <entry>or</entry> </row> <row> <entry>local/<hostname>:<path></entry> <entry></entry> </row> </tbody> </tgroup> </informaltable> <para>Most protocol libraries will have some sort of open function that should internally make a call into <xref linkend='IceOpenConnection' xrefstyle='select: title'/> When <xref linkend='IceOpenConnection' xrefstyle='select: title'/> 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 connections are not desired.</para> <para>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.</para> <para>In addition, if major_opcode_check contains a nonzero 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 connections between two clients for the same protocol.</para> <para>Any authentication requirements are handled internally by the ICE library. The method by which the authentication data is obtained is implementation-dependent. <footnote remap='FS'> <para>The X Consortium's ICElib implementation uses an .ICEauthority file (see Appendix A). </para></footnote> </para> <para>After <xref linkend='IceOpenConnection' xrefstyle='select: title'/> is called, the client is ready to send a <function>ProtocolSetup</function> (provided that <xref linkend='IceRegisterForProtocolSetup' xrefstyle='select: title'/> was called) or receive a <function>ProtocolSetup</function> (provided that <xref linkend='IceRegisterForProtocolReply' xrefstyle='select: title'/> was called).</para> </sect1> <sect1 id='Listening_for_ICE_Connections'> <title>Listening for ICE Connections</title> <para>Clients wishing to accept ICE connections must first call <xref linkend='IceListenForConnections' xrefstyle='select: title'/> or <xref linkend='IceListenForWellKnownConnections' xrefstyle='select: title'/> so that 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, and so on).</para> <para>Normally clients will let ICElib allocate an available name in each transport and return listen objects. Such a client will then use <xref linkend='IceComposeNetworkIdList' xrefstyle='select: title'/> to extract the chosen names and make them available to other clients for opening the connection. In certain cases it may be necessary for a client to listen for connections on pre-arranged transport object names. Such a client may use <xref linkend='IceListenForWellKnownConnections' xrefstyle='select: title'/> to specify the names for the listen objects.</para> <funcsynopsis id='IceListenForConnections'> <funcprototype> <funcdef>Status <function>IceListenForConnections</function></funcdef> <paramdef>int<parameter> *count_ret</parameter></paramdef> <paramdef>IceListenObj<parameter> **listen_objs_ret</parameter></paramdef> <paramdef>int<parameter> error_length</parameter></paramdef> <paramdef>char<parameter> *error_string_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>count_ret</emphasis></term> <listitem><para>Returns the number of listen objects created.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>listen_objs_ret</emphasis></term> <listitem><para>Returns a list of pointers to opaque listen objects.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_length</emphasis></term> <listitem> <para>The length of the error_string_ret argument passed in.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_string_ret</emphasis></term> <listitem> <para>Returns a null-terminated error message, if any. The error_string_ret points to user supplied memory. No more than error_length bytes are used.</para> </listitem> </varlistentry> </variablelist> <para>The return value of <xref linkend='IceListenForConnections' xrefstyle='select: title'/> is zero for failure and a positive value for success.</para> <funcsynopsis id='IceListenForWellKnownConnections'> <funcprototype> <funcdef>Status <function>IceListenForWellKnownConnections</function></funcdef> <paramdef>char<parameter> *port_id</parameter></paramdef> <paramdef>int<parameter> *count_ret</parameter></paramdef> <paramdef>IceListenObj<parameter> **listen_objs_ret</parameter></paramdef> <paramdef>int<parameter> error_length</parameter></paramdef> <paramdef>char<parameter> *error_string_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>port_id</emphasis></term> <listitem> <para> Specifies the port identification for the address(es) to be opened. The value must not contain the slash ("/"> or comma (".") character; thse are reserved for future use. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>count_ret</emphasis></term> <listitem> <para>Returns the number of listen objects created.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>listen_objs_ret</emphasis></term> <listitem> <para> Returns a list of pointers to opaque listen objects. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>listen_objs_ret</emphasis></term> <listitem> <para> Returns a list of pointers to opaque listen objects. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_length</emphasis></term> <listitem> <para> The length of the error_string_ret argument passed in. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_string_ret</emphasis></term> <listitem> <para> Returns a null-terminated error message, if any. The error_string_ret points to user supplied memory. No more than error_length bytes are used. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceListenForWellKnownConnections' xrefstyle='select: title'/> constructs a list of network IDs by prepending each known transport to port_id and then attempts to create listen objects for the result. Port_id is the portnumber, objname, or path portion of the ICE network ID. If a listen object for a particular network ID cannot be created the network ID is ignored. If no listen objects are created <xref linkend='IceListenForWellKnownConnections' xrefstyle='select: title'/> returns failure. </para> <para> The return value of <xref linkend='IceListenForWellKnownConnections' xrefstyle='select: title'/> is zero for failure and a positive value for success. </para> <para> To close and free the listen objects, use <xref linkend='IceFreeListenObjs' xrefstyle='select: title'/> </para> <funcsynopsis id='IceFreeListenObjs'> <funcprototype> <funcdef>void <function>IceFreeListenObjs</function></funcdef> <paramdef>int<parameter> count</parameter></paramdef> <paramdef>IceListenObj<parameter> *listen_objs</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>count</emphasis></term> <listitem> <para>The number of listen objects.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>listen_objs</emphasis></term> <listitem> <para>The listen objects.</para> </listitem> </varlistentry> </variablelist> <para> To detect a new connection on a listen object, use <function>select</function> on the descriptor associated with the listen object. </para> <para> To obtain the descriptor, use <xref linkend='IceGetListenConnectionNumber' xrefstyle='select: title'/> </para> <funcsynopsis id='IceGetListenConnectionNumber'> <funcprototype> <funcdef>int <function>IceGetListenConnectionNumber</function></funcdef> <paramdef>IceListenObj<parameter> *listen_objs</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>listen_obj</emphasis></term> <listitem> <para>The listen objects.</para> </listitem> </varlistentry> </variablelist> <para> To obtain the network ID string associated with a listen object, use <xref linkend='IceGetListenConnectionString' xrefstyle='select: title'/> </para> <funcsynopsis id='IceGetListenConnectionString'> <funcprototype> <funcdef>char <function>IceGetListenConnectionString</function></funcdef> <paramdef>IceListenObj<parameter> listen_obj</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>listen_obj</emphasis></term> <listitem> <para>The listen objects.</para> </listitem> </varlistentry> </variablelist> <para>A network ID has the following format:</para> <informaltable frame='none'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='2.0*'/> <tbody> <row> <entry>tcp/<hostname>:<portnumber></entry> <entry>or</entry> </row> <row> <entry>decnet/<hostname>::<objname></entry> <entry>or</entry> </row> <row> <entry>local/<hostname>:<path></entry> <entry></entry> </row> </tbody> </tgroup> </informaltable> <para> To compose a string containing a list of network IDs separated by commas (the format recognized by <xref linkend='IceOpenConnection' xrefstyle='select: title'/> use <xref linkend='IceComposeNetworkIdList' xrefstyle='select: title'/> </para> <funcsynopsis id='IceComposeNetworkIdList'> <funcprototype> <funcdef>char <function>IceComposeNetworkIdList</function></funcdef> <paramdef>int<parameter> count</parameter></paramdef> <paramdef>IceListenObj<parameter> *listen_objs</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>count</emphasis></term> <listitem> <para>The number of listen objects.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>listen_objs</emphasis></term> <listitem> <para>The listen objects.</para> </listitem> </varlistentry> </variablelist> </sect1> <sect1 id='Host_Based_Authentication_for_ICE_Connections'> <title>Host Based Authentication for ICE Connections</title> <para> 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 <xref linkend='IceSetHostBasedAuthProc' xrefstyle='select: title'/> function. </para> <funcsynopsis id='IceSetHostBasedAuthProc'> <funcprototype> <funcdef>void <function>IceSetHostBasedAuthProc</function></funcdef> <paramdef>IceListenObj<parameter> listen_obj</parameter></paramdef> <paramdef>IceHostBasedAuthProc<parameter> host_based_auth_proc</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>IceListenObj</emphasis></term> <listitem> <para>The listen object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>host_based_auth_proc</emphasis></term> <listitem> <para>The host based authentication procedure.</para> </listitem> </varlistentry> </variablelist> <para> 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. </para> <funcsynopsis id='HostBasedAuthProc'> <funcprototype> <funcdef>Bool <function>HostBasedAuthProc</function></funcdef> <paramdef>char<parameter> *host_name</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>host_name</emphasis></term> <listitem> <para> The host name of the client that tried to open an ICE connection. </para> </listitem> </varlistentry> </variablelist> <para> The host_name argument is a string in the form <emphasis remap='I'>protocol</emphasis>/ <emphasis remap='I'>hostname</emphasis>, where <emphasis remap='I'>protocol</emphasis> is one of {tcp, decnet, local}. </para> <para> If <function>IceHostBasedAuthProc</function> returns <function>True</function> access will be granted, even though the original authentication failed. Note that authentication can effectively be disabled by registering an <function>IceHostBasedAuthProc</function> which always returns <function>True</function> </para> <para> Host based authentication is also allowed at <function>ProtocolSetup</function> time. The callback is specified in the <xref linkend='IceRegisterForProtocolReply' xrefstyle='select: title'/> function (see <xref linkend='Protocol_Registration' xrefstyle='select: title'/>). </para> </sect1> <sect1 id='Accepting_ICE_Connections'> <title>Accepting ICE Connections</title> <para> After a connection attempt is detected on a listen object returned by <xref linkend='IceListenForConnections' xrefstyle='select: title'/> you should call <xref linkend='IceAcceptConnection' xrefstyle='select: title'/> This returns a new opaque ICE connection object. </para> <funcsynopsis id='IceAcceptConnection'> <funcprototype> <funcdef>IceConn <function>IceAcceptConnection</function></funcdef> <paramdef>IceListenObj<parameter> listen_obj</parameter></paramdef> <paramdef>IceAcceptStatus<parameter> *status_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>listen_obj</emphasis></term> <listitem> <para>The listen object on which a new connection was detected.</para> </listitem> </varlistentry> </variablelist> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>status_ret</emphasis></term> <listitem> <para>Return status information.</para> </listitem> </varlistentry> </variablelist> <para>The status_ret argument is set to one of the following values:</para> <itemizedlist> <listitem> <para><function>IceAcceptSuccess</function> - the accept operation succeeded, and the function returns a new connection object.</para> </listitem> <listitem> <para><function>IceAcceptFailure</function> - the accept operation failed, and the function returns NULL.</para> </listitem> <listitem> <para><function>IceAcceptBadMalloc</function> - a memory allocation failed, and the function returns NULL.</para> </listitem> </itemizedlist> <para>In general, to detect new connections, you should call <function>select</function> on the file descriptors associated with the listen objects. When a new connection is detected, the <xref linkend='IceAcceptConnection' xrefstyle='select: title'/> function should be called. <xref linkend='IceAcceptConnection' xrefstyle='select: title'/> 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. Because 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.</para> <para>The following pseudo-code demonstrates how connections are accepted:</para> <literallayout class="monospaced"> new_ice_conn = IceAcceptConnection (listen_obj, &accept_status); if (accept_status != IceAcceptSuccess) { close the file descriptor and return } status = IceConnectionStatus (new_ice_conn); time_start = time_now; while (status == IceConnectPending) { select() on {new_ice_conn, all open connections} for (each ice_conn in the list of open connections) if (data ready on ice_conn) { 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_conn); } else { if (time_now - time_start > MAX_WAIT_TIME) status = IceConnectRejected; } } if (status == IceConnectAccepted) { Add new_ice_conn to the list of open connections } else { IceCloseConnection new_ice_conn } </literallayout> <para>After <xref linkend='IceAcceptConnection' xrefstyle='select: title'/> is called and the connection has been validated, the client is ready to receive a <function>ProtocolSetup</function> (provided that <xref linkend='IceRegisterForProtocolReply' xrefstyle='select: title'/> was called) or send a <function>ProtocolSetup</function> (provided that <xref linkend='IceRegisterForProtocolSetup' xrefstyle='select: title'/> was called).</para> </sect1> <sect1 id='Closing_ICE_Connections'> <title>Closing ICE Connections</title> <para>To close an ICE connection created with <xref linkend='IceOpenConnection' xrefstyle='select: title'/> or <xref linkend='IceAcceptConnection' xrefstyle='select: title'/> use <xref linkend='IceCloseConnection' xrefstyle='select: title'/></para> <funcsynopsis id='IceCloseConnection'> <funcprototype> <funcdef>IceCloseStatus <function>IceCloseConnection</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>The ICE connection to close.</para> </listitem> </varlistentry> </variablelist> <para>To actually close an ICE connection, the following conditions must be met:</para> <itemizedlist> <listitem> <para>The <emphasis remap='I'>open reference count</emphasis> must have reached zero on this ICE connection. When <xref linkend='IceOpenConnection' xrefstyle='select: title'/> is called, it tries to use a previously opened ICE connection. If it is able to use an existing connection, it increments the open reference count on the connection by one. So, to close an ICE connection, each call to <xref linkend='IceOpenConnection' xrefstyle='select: title'/> must be matched with a call to <xref linkend='IceCloseConnection' xrefstyle='select: title'/> The connection can be closed only on the last call to <xref linkend='IceCloseConnection' xrefstyle='select: title'/></para> </listitem> <listitem> <para>The <emphasis remap='I'>active protocol count</emphasis> must have reached zero. Each time a <function>ProtocolSetup</function> succeeds on the connection, the active protocol count is incremented by one. When the client no longer expects to use the protocol on the connection, the <xref linkend='IceProtocolShutdown' xrefstyle='select: title'/> function should be called, which decrements the active protocol count by one (see <xref linkend='Protocol_Setup_and_Shutdown' xrefstyle='select: title'/>). </para> </listitem> <listitem> <para>If shutdown negotiation is enabled on the connection, the client on the other side of the ICE connection must agree to have the connection closed.</para> <para><xref linkend='IceCloseConnection' xrefstyle='select: title'/> returns one of the following values:</para> </listitem> <listitem> <para><function>IceClosedNow</function> - the ICE connection was closed at this time. The watch procedures were invoked and the connection was freed.</para> </listitem> <listitem> <para><function>IceClosedASAP</function> - an IO error had occurred on the connection, but <xref linkend='IceCloseConnection' xrefstyle='select: title'/> is being called within a nested <xref linkend='IceProcessMessages' xrefstyle='select: title'/> 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 <xref linkend='IceProcessMessages' xrefstyle='select: title'/> returns a status of <function>IceProcessMessagesConnectionClosed</function></para> </listitem> <listitem> <para><function>IceConnectionInUse</function> - the connection was not closed at this time, because it is being used by other active protocols.</para> </listitem> <listitem> <para><function>IceStartedShutdownNegotiation</function> - the connection was not closed at this time and shutdown negotiation started with the client on the other side of the ICE connection. When the connection is actually closed, <xref linkend='IceProcessMessages' xrefstyle='select: title'/> will return a status of <function>IceProcessMessagesConnectionClosed</function></para> </listitem> </itemizedlist> <para>When it is known that the client on the other side of the ICE connection has terminated the connection without initiating shutdown negotiation, the <xref linkend='IceSetShutdownNegotiation' xrefstyle='select: title'/> function should be called to turn off shutdown negotiation. This will prevent <xref linkend='IceCloseConnection' xrefstyle='select: title'/> from writing to a broken connection.</para> <funcsynopsis id='IceSetShutdownNegotiation'> <funcprototype> <funcdef>void <function>IceSetShutdownNegotiation</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>Bool<parameter> negotiate</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>negotiate</emphasis></term> <listitem> <para>If <function>False</function> shutdown negotiating will be turned off.</para> </listitem> </varlistentry> </variablelist> <para>To check the shutdown negotiation status of an ICE connection, use <xref linkend='IceCheckShutdownNegotiation' xrefstyle='select: title'/></para> <funcsynopsis id='IceCheckShutdownNegotiation'> <funcprototype> <funcdef>Bool <function>IceCheckShutdownNegotiation</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> </variablelist> <para><xref linkend='IceCheckShutdownNegotiation' xrefstyle='select: title'/> returns <function>True</function> if shutdown negotiation will take place on the connection; otherwise, it returns <function>False</function> Negotiation is on by default for a connection. It can only be changed with the <xref linkend='IceSetShutdownNegotiation' xrefstyle='select: title'/> function.</para> </sect1> <sect1 id='Connection_Watch_Procedures'> <title>Connection Watch Procedures</title> <para>To add a watch procedure that will be called each time ICElib opens a new connection via <xref linkend='IceOpenConnection' xrefstyle='select: title'/> or <xref linkend='IceAcceptConnection' xrefstyle='select: title'/> or closes a connection via <xref linkend='IceCloseConnection' xrefstyle='select: title'/> use <xref linkend='IceAddConnectionWatch' xrefstyle='select: title'/></para> <funcsynopsis id='IceAddConnectionWatch'> <funcprototype> <funcdef>Status <function>IceAddConnectionWatch</function></funcdef> <paramdef>IceWatchProc<parameter> watch_proc</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>watch_proc</emphasis></term> <listitem> <para> The watch procedure to invoke when ICElib opens or closes a connection. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para>This pointer will be passed to the watch procedure.</para> </listitem> </varlistentry> </variablelist> <para> The return value of <xref linkend='IceAddConnectionWatch' xrefstyle='select: title'/> is zero for failure, and a positive value for success. </para> <para> Note that several calls to <xref linkend='IceOpenConnection' xrefstyle='select: title'/> 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, because connections might be shared, the watch procedure is called only if <xref linkend='IceCloseConnection' xrefstyle='select: title'/> actually closes the connection (right before the IceConn is freed). </para> <para> The watch procedures are very useful for applications that need to add a file descriptor to a select mask when a new connection is created and remove the file descriptor when the connection is destroyed. Because connections are shared, knowing when to add and remove the file descriptor from the select mask would be difficult without the watch procedures. </para> <para> Multiple watch procedures may be registered with the ICE library. No assumptions should be made about their order of invocation. </para> <para> If one or more ICE connections were already created by the ICE library at the time the watch procedure is registered, the watch procedure will instantly be invoked for each of these ICE connections (with the opening argument set to <function>True</function> </para> <para> The watch procedure is of type <function>IceWatchProc</function> </para> <funcsynopsis id='WatchProc'> <funcprototype> <funcdef>void <function>WatchProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> <paramdef>Bool<parameter> opening</parameter></paramdef> <paramdef>IcePointer<parameter> *watch_data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para> The opened or closed ICE connection. Call <function>IceConnectionNumber</function> to get the file descriptor associated with this connection. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para> Client data specified in the call to <xref linkend='IceAddConnectionWatch' xrefstyle='select: title'/> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>opening</emphasis></term> <listitem> <para> If <function>True</function> the connection is being opened. If <function>False</function> the connection is being closed. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>watch_data</emphasis></term> <listitem> <para>Can be used to save a pointer to client data.</para> </listitem> </varlistentry> </variablelist> <para> If opening is <function>True</function> 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 <function>False</function> </para> <para> To remove a watch procedure, use <xref linkend='IceRemoveConnectionWatch' xrefstyle='select: title'/> </para> <funcsynopsis id='IceRemoveConnectionWatch'> <funcprototype> <funcdef>void <function>IceRemoveConnectionWatch</function></funcdef> <paramdef>IceWatchProc<parameter> watch_proc</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>watch_proc</emphasis></term> <listitem> <para> The watch procedure that was passed to <xref linkend='IceAddConnectionWatch' xrefstyle='select: title'/> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para> The client_data pointer that was passed to <xref linkend='IceAddConnectionWatch' xrefstyle='select: title'/> </para> </listitem> </varlistentry> </variablelist> </sect1> </chapter> <chapter id='Protocol_Setup_and_Shutdown'> <title>Protocol Setup and Shutdown</title> <para> To activate a protocol on a given ICE connection, use <xref linkend='IceProtocolSetup' xrefstyle='select: title'/> </para> <funcsynopsis id='IceProtocolSetup'> <funcprototype> <funcdef>IceProtocolSetupStatus <function>IceProtocolSetup</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> my_opcode</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> <paramdef>Bool<parameter> must_authenticate</parameter></paramdef> <paramdef>int<parameter> *major_version_ret</parameter></paramdef> <paramdef>int<parameter> *minor_version_ret</parameter></paramdef> <paramdef>char<parameter> **vendor_ret</parameter></paramdef> <paramdef>char<parameter> **release_ret</parameter></paramdef> <paramdef>int<parameter> error_length</parameter></paramdef> <paramdef>char<parameter> *error_string_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>my_opcode</emphasis></term> <listitem> <para> The major opcode of the protocol to be set up, as returned by <xref linkend='IceRegisterForProtocolSetup' xrefstyle='select: title'/> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para> The client data stored in this pointer will be passed to the <function>IcePoProcessMsgProc</function> callback. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>must_authenticate</emphasis></term> <listitem> <para> If <function>True</function> the other client may not bypass authentication. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_version_ret</emphasis></term> <listitem> <para>The major version of the protocol to be used is returned.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>minor_version_ret</emphasis></term> <listitem> <para>The minor version of the protocol to be used is returned.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>vendor_ret</emphasis></term> <listitem> <para>The vendor string specified by the protocol acceptor.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>release_ret</emphasis></term> <listitem> <para>The release string specified by the protocol acceptor.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_length</emphasis></term> <listitem> <para> Specifies the length of the error_string_ret argument passed in. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_string_ret</emphasis></term> <listitem> <para> Returns a null-terminated error message, if any. The error_string_ret argument points to user supplied memory. No more than error_length bytes are used. </para> </listitem> </varlistentry> </variablelist> <para> The vendor_ret and release_ret strings should be freed with <function>free</function> when no longer needed. </para> <para> <xref linkend='IceProtocolSetup' xrefstyle='select: title'/> returns one of the following values: </para> <itemizedlist> <listitem> <para> <function>IceProtocolSetupSuccess</function> - the major_version_ret, minor_version_ret, vendor_ret, release_ret are set. </para> </listitem> <listitem> <para> <function>IceProtocolSetupFailure</function> or <function>IceProtocolSetupIOError</function> - check error_string_ret for failure reason. The major_version_ret, minor_version_ret, vendor_ret, release_ret are not set. </para> </listitem> <listitem> <para> <function>IceProtocolAlreadyActive</function> - this protocol is already active on this connection. The major_version_ret, minor_version_ret, vendor_ret, release_ret are not set. </para> </listitem> </itemizedlist> <para> To notify the ICE library when a given protocol will no longer be used on an ICE connection, use <xref linkend='IceProtocolShutdown' xrefstyle='select: title'/> </para> <funcsynopsis id='IceProtocolShutdown'> <funcprototype> <funcdef>Status <function>IceProtocolShutdown</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> major_opcode</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_opcode</emphasis></term> <listitem> <para>The major opcode of the protocol to shut down.</para> </listitem> </varlistentry> </variablelist> <para> The return value of <xref linkend='IceProtocolShutdown' xrefstyle='select: title'/> is zero for failure and a positive value for success. </para> <para> 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 <function>ProtocolSetup</function> succeeded on the connection. Note that ICE does not define how each sub-protocol triggers a protocol shutdown. </para> </chapter> <chapter id='Processing_Messages'> <title>Processing Messages</title> <para>To process incoming messages on an ICE connection, use <xref linkend='IceProcessMessages' xrefstyle='select: title'/></para> <funcsynopsis id='IceProcessMessages'> <funcprototype> <funcdef>IceProcessMessagesStatus <function>IceProcessMessages</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IceReplyWaitInfo<parameter> *reply_wait</parameter></paramdef> <paramdef>Bool<parameter> *reply_ready_ret</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_wait</emphasis></term> <listitem> <para>Indicates if a reply is being waited for.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>reply_ready_ret</emphasis></term> <listitem> <para> If set to <function>True</function> on return, a reply is ready. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceProcessMessages' xrefstyle='select: title'/> is used in two ways: </para> <itemizedlist> <listitem> <para> In the first, a client may generate a message and block by calling <xref linkend='IceProcessMessages' xrefstyle='select: title'/> repeatedly until it gets its reply. </para> </listitem> <listitem> <para> In the second, a client calls <xref linkend='IceProcessMessages' xrefstyle='select: title'/> with reply_wait set to NULL in response to <function>select</function> showing that there is data to read on the ICE connection. The ICE library may process zero or more complete messages. Note that messages that are not blocked for are always processed by invoking callbacks. </para> </listitem> </itemizedlist> <para> <function>IceReplyWaitInfo</function> 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 <function>IcePointer</function> 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 <function>IcePoProcessMsgProc</function> 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 (for example, 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 <function>IcePoProcessMsgProc</function> callback would allocate the storage and store the pointer. It is the responsibility of the client receiving the reply to free up any memory allocated on its behalf. </para> <literallayout class="monospaced"> typedef struct { unsigned long sequence_of_request; int major_opcode_of_request; int minor_opcode_of_request; IcePointer reply; } IceReplyWaitInfo; </literallayout> <para> If reply_wait is not NULL and <xref linkend='IceProcessMessages' xrefstyle='select: title'/> has a reply or error to return in response to this reply_wait (that is, no callback was generated), then the reply_ready_ret argument will be set to <function>True</function> </para> <para> 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. </para> <para> <xref linkend='IceProcessMessages' xrefstyle='select: title'/> returns one of the following values: </para> <itemizedlist> <listitem> <para> <function>IceProcessMessagesSuccess</function> - no error occurred. </para> </listitem> <listitem> <para> <function>IceProcessMessagesIOError</function> - an IO error occurred, and the caller must explicitly close the connection by calling <xref linkend='IceCloseConnection' xrefstyle='select: title'/> </para> </listitem> <listitem> <para> <function>IceProcessMessagesConnectionClosed</function> - the ICE connection has been closed (closing of the connection was deferred because of shutdown negotiation, or because the <xref linkend='IceProcessMessages' xrefstyle='select: title'/> nesting level was not zero). Do not attempt to access the ICE connection at this point, since it has been freed. </para> </listitem> </itemizedlist> </chapter> <chapter id='Ping'> <title>Ping</title> <para> To send a "Ping" message to the client on the other side of the ICE connection, use <xref linkend='IcePing' xrefstyle='select: title'/> </para> <funcsynopsis id='IcePing'> <funcprototype> <funcdef>Status <function>IcePing</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePingReplyProc<parameter> ping_reply_proc</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>ping_reply_proc</emphasis></term> <listitem> <para>The callback to invoke when the Ping reply arrives.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para> This pointer will be passed to the <olink targetdoc='SMlib' targetptr='IcePingReplyProc'><function>IcePingReplyProc</function></olink> callback. </para> </listitem> </varlistentry> </variablelist> <para><xref linkend='IcePing' xrefstyle='select: title'/> returns zero for failure and a positive value for success.</para> <para>When <xref linkend='IceProcessMessages' xrefstyle='select: title'/> processes the Ping reply, it will invoke the <olink targetdoc='SMlib' targetptr='IcePingReplyProc'><function>IcePingReplyProc</function></olink> callback.</para> <funcsynopsis id='PingReplyProc'> <funcprototype> <funcdef>void <function>PingReplyProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>IcePointer<parameter> client_data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>client_data</emphasis></term> <listitem> <para>The client data specified in the call to <xref linkend='IcePing' xrefstyle='select: title'/></para> </listitem> </varlistentry> </variablelist> </chapter> <chapter id='Using_ICElib_Informational_Functions'> <title>Using ICElib Informational Functions</title> <funcsynopsis id='IceConnectionStatus'> <funcprototype> <funcdef>IceConnectStatus <function>IceConnectionStatus</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><xref linkend='IceConnectionStatus' xrefstyle='select: title'/> returns the status of an ICE connection. The possible return values are:</para> <itemizedlist> <listitem> <para><function>IceConnectPending</function> - the connection is not valid yet (that is, authentication is taking place). This is only relevant to connections created by <xref linkend='IceAcceptConnection' xrefstyle='select: title'/></para> </listitem> <listitem> <para><function>IceConnectAccepted</function> - the connection has been accepted. This is only relevant to connections created by <xref linkend='IceAcceptConnection' xrefstyle='select: title'/></para> </listitem> <listitem> <para><function>IceConnectRejected</function> - the connection had been rejected (that is, authentication failed). This is only relevant to connections created by <xref linkend='IceAcceptConnection' xrefstyle='select: title'/></para> </listitem> <listitem> <para><function>IceConnectIOError</function> - an IO error has occurred on the connection.</para> </listitem> </itemizedlist> <funcsynopsis id='IceVendor'> <funcprototype> <funcdef>char <function> *IceVendor</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><function>IceVendor</function> returns the ICE library vendor identification for the other side of the connection. The string should be freed with a call to <function>free</function> when no longer needed.</para> <funcsynopsis id='IceRelease'> <funcprototype> <funcdef>char <function> *IceRelease</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><function>IceRelease</function> returns the release identification of the ICE library on the other side of the connection. The string should be freed with a call to <function>free</function> when no longer needed.</para> <funcsynopsis id='IceProtocolVersion'> <funcprototype> <funcdef>int <function> IceProtocolVersion</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><xref linkend='IceProtocolVersion' xrefstyle='select: title'/> returns the major version of the ICE protocol on this connection.</para> <funcsynopsis id='IceProtocolRevision'> <funcprototype> <funcdef>int <function> IceProtocolRevision</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><xref linkend='IceProtocolRevision' xrefstyle='select: title'/> returns the minor version of the ICE protocol on this connection.</para> <funcsynopsis> <funcprototype> <funcdef>int <function> IceConnectionNumber</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><function>IceConnectionNumber</function> returns the file descriptor of this ICE connection.</para> <funcsynopsis id='IceConnectionString'> <funcprototype> <funcdef>char <function> *IceConnectionString</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><function>IceConnectionString</function> returns the network ID of the client that accepted this connection. The string should be freed with a call to <function>free</function> when no longer needed.</para> <funcsynopsis id='IceLastSentSequenceNumber'> <funcprototype> <funcdef>unsigned long <function> IceLastSentSequenceNumber</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><xref linkend='IceLastSentSequenceNumber' xrefstyle='select: title'/> returns the sequence number of the last message sent on this ICE connection.</para> <funcsynopsis> <funcprototype> <funcdef>unsigned long <function> IceLastReceivedSequenceNumber</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><function>IceLastReceivedSequenceNumber</function> returns the sequence number of the last message received on this ICE connection.</para> <funcsynopsis id='IceSwapping'> <funcprototype> <funcdef>Bool <function> IceSwapping</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><xref linkend='IceSwapping' xrefstyle='select: title'/> returns <function>True</function> if byte swapping is necessary when reading messages on the ICE connection.</para> <funcsynopsis id='IceGetContext'> <funcprototype> <funcdef>IcePointer <function> IceGetContext</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <para><xref linkend='IceGetContext' xrefstyle='select: title'/> returns the context associated with a connection created by <xref linkend='IceOpenConnection' xrefstyle='select: title'/></para> </chapter> <chapter id='ICE_Messages'> <title>ICE Messages</title> <para> All ICE messages have a standard 8-byte header. The ICElib macros that read and write messages rely on the following naming convention for message headers: </para> <literallayout class='monospaced'> CARD8 major_opcode; CARD8 minor_opcode; CARD8 data[2]; CARD32 length; </literallayout> <para> The 3rd and 4th bytes of the message header can be used as needed. The length field is specified in units of 8 bytes. </para> <sect1 id='Sending_ICE_Messages'> <title>Sending ICE Messages</title> <para> 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. </para> <para> If an IO error has occurred on an ICE connection, all write operations will be ignored. For further information, see <xref linkend='Error_Handling' xrefstyle='select: title'/>. </para> <para> To get the size of the ICE output buffer, use <xref linkend='IceGetOutBufSize' xrefstyle='select: title'/> </para> <funcsynopsis id='IceGetOutBufSize'> <funcprototype> <funcdef>int <function> IceGetOutBufSize</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> </variablelist> <para> To flush the ICE output buffer, use <xref linkend='IceFlush' xrefstyle='select: title'/> </para> <funcsynopsis id='IceFlush'> <funcprototype> <funcdef>int <function> IceFlush</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> </variablelist> <para> Note that the output buffer may be implicitly flushed if there is insufficient space to generate a message. </para> <para>The following macros can be used to generate ICE messages:</para> <funcsynopsis id='IceGetHeader'> <funcprototype> <funcdef><function> IceGetHeader</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> major_opcode</parameter></paramdef> <paramdef>int<parameter> minor_opcode</parameter></paramdef> <paramdef>int<parameter> header_size</parameter></paramdef> <paramdef><C_data_type><parameter> *pmsg</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_opcode</emphasis></term> <listitem> <para>The major opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>minor_opcode</emphasis></term> <listitem> <para>The minor opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>header_size</emphasis></term> <listitem> <para>The size of the message header (in bytes).</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'><C_data_type></emphasis></term> <listitem> <para>The actual C data type of the message header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pmsg</emphasis></term> <listitem> <para> The message header pointer. After this macro is called, the library can store data in the message header. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceGetHeader' xrefstyle='select: title'/> 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. </para> <funcsynopsis id='IceGetHeaderExtra'> <funcprototype> <funcdef><function> IceGetHeaderExtra</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> major_opcode</parameter></paramdef> <paramdef>int<parameter> minor_opcode</parameter></paramdef> <paramdef>int<parameter> header_size</parameter></paramdef> <paramdef>int<parameter> extra</parameter></paramdef> <paramdef><C_data_type><parameter> *pmsg</parameter></paramdef> <paramdef>char<parameter> *pdata</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_opcode</emphasis></term> <listitem> <para>The major opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>minor_opcode</emphasis></term> <listitem> <para>The minor opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>header_size</emphasis></term> <listitem> <para>The size of the message header (in bytes).</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>extra</emphasis></term> <listitem> <para> The size of the extra data beyond the header (in 8-byte units). </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'><C_data_type></emphasis></term> <listitem> <para>The actual C data type of the message header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pmsg</emphasis></term> <listitem> <para> The message header pointer. After this macro is called, the library can store data in the message header. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pdata</emphasis></term> <listitem> <para> Returns a pointer to the ICE output buffer that 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. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceGetHeaderExtra' xrefstyle='select: title'/> 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. </para> <funcsynopsis id='IceSimpleMessage'> <funcprototype> <funcdef><function> IceSimpleMessage</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> major_opcode</parameter></paramdef> <paramdef>int<parameter> minor_opcode</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>major_opcode</emphasis></term> <listitem> <para>The major opcode of the message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>minor_opcode</emphasis></term> <listitem> <para>The minor opcode of the message.</para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceSimpleMessage' xrefstyle='select: title'/> is used to generate a message that is identical in size to the ICE header message, and has no additional data. </para> <funcsynopsis id='IceErrorHeader'> <funcprototype> <funcdef><function> IceErrorHeader</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> offending_major_opcode</parameter></paramdef> <paramdef>int<parameter> offending_minor_opcode</parameter></paramdef> <paramdef>int<parameter> offending_sequence_num</parameter></paramdef> <paramdef>int<parameter> severity</parameter></paramdef> <paramdef>int<parameter> error_class</parameter></paramdef> <paramdef>int<parameter> data_length</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>offending_major_opcode</emphasis></term> <listitem> <para> The major opcode of the protocol in which an error was detected. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>offending_minor_opcode</emphasis></term> <listitem> <para> The minor opcode of the protocol in which an error was detected. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>offending_sequence_num</emphasis></term> <listitem> <para>The sequence number of the message that caused the error.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis></term> <listitem> <para> <function>IceCanContinue</function> <function>IceFatalToProtocol</function> or <function>IceFatalToConnection</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_class</emphasis></term> <listitem> <para>The error class.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data_length</emphasis></term> <listitem> <para> Length of data (in 8-byte units) to be written after the header. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceErrorHeader' xrefstyle='select: title'/> sets up an error message header. </para> <para> 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. </para> <para> Generic errors, which are common to all protocols, have classes in the range 0x8000..0xFFFF. See the <emphasis remap='I'>Inter-Client Exchange Protocol</emphasis> standard for more details. </para> <informaltable frame='none'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='2.0*'/> <tbody> <row> <entry>IceBadMinor</entry> <entry>0x8000</entry> </row> <row> <entry>IceBadState</entry> <entry>0x8001</entry> </row> <row> <entry>IceBadLength</entry> <entry>0x8002</entry> </row> <row> <entry>IceBadValue</entry> <entry>0x8003</entry> </row> </tbody> </tgroup> </informaltable> <para>Per-protocol errors have classes in the range 0x0000-0x7fff.</para> <para> To write data to an ICE connection, use the <xref linkend='IceWriteData' xrefstyle='select: title'/> 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. </para> <para> This macro is used in conjunction with <xref linkend='IceGetHeader' xrefstyle='select: title'/> and <xref linkend='IceErrorHeader' xrefstyle='select: title'/> </para> <funcsynopsis id='IceWriteData'> <funcprototype> <funcdef><function> IceWriteData</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to write.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data</emphasis></term> <listitem> <para>The data to write.</para> </listitem> </varlistentry> </variablelist> <para> To write data as 16-bit quantities, use <xref linkend='IceWriteData16' xrefstyle='select: title'/> </para> <funcsynopsis id='IceWriteData16'> <funcprototype> <funcdef><function> IceWriteData16</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to write.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data</emphasis></term> <listitem> <para>The data to write.</para> </listitem> </varlistentry> </variablelist> <para> To write data as 32-bit quantities, use <xref linkend='IceWriteData32' xrefstyle='select: title'/> </para> <funcsynopsis id='IceWriteData32'> <funcprototype> <funcdef><function> IceWriteData32</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to write.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data</emphasis></term> <listitem> <para>The data to write.</para> </listitem> </varlistentry> </variablelist> <para> To write data as 32-bit quantities, use <xref linkend='IceWriteData32' xrefstyle='select: title'/> </para> <para> To bypass copying data to the ICE output buffer, use <xref linkend='IceSendData' xrefstyle='select: title'/> to directly send data over the network connection. If necessary, the ICE output buffer is first flushed. </para> <funcsynopsis id='IceSendData'> <funcprototype> <funcdef><function> IceSendData</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to send.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data</emphasis></term> <listitem> <para>The data to send.</para> </listitem> </varlistentry> </variablelist> <para> To force 32-bit or 64-bit alignment, use <xref linkend='IceWritePad' xrefstyle='select: title'/> A maximum of 7 pad bytes can be specified. </para> <funcsynopsis id='IceWritePad'> <funcprototype> <funcdef><function> IceWritePad</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *data</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to write.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>data</emphasis></term> <listitem> <para>The number of pad bytes to write.</para> </listitem> </varlistentry> </variablelist> </sect1> <sect1 id='Reading_ICE_Messages'> <title>Reading ICE Messages</title> <para> The ICE library maintains an input buffer used for reading messages. If the ICE library chooses to perform nonblocking 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 that read messages, an actual read operation will occur on the connection only if the data is not already present in the input buffer. </para> <para> To get the size of the ICE input buffer, use <xref linkend='IceGetInBufSize' xrefstyle='select: title'/> </para> <funcsynopsis id='IceGetInBufSize'> <funcprototype> <funcdef>int<function> IceGetInBufSize</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> </variablelist> <para> 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 <xref linkend='IceValidIO' xrefstyle='select: title'/> 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. For further information, see <xref linkend='Error_Handling' xrefstyle='select: title'/>. </para> <funcsynopsis id='IceValidIO'> <funcprototype> <funcdef>Bool<function> IceValidIO</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> </variablelist> <para>The following macros can be used to read ICE messages.</para> <funcsynopsis id='IceReadSimpleMessage'> <funcprototype> <funcdef><function> IceReadSimpleMessage</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef><C_data_type><parameter> *pmsg</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'><C_data_type></emphasis></term> <listitem> <para>The actual C data type of the message header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pmsg</emphasis></term> <listitem> <para>This pointer is set to the message header.</para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceReadSimpleMessage' xrefstyle='select: title'/> is used for messages that 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. <xref linkend='IceReadSimpleMessage' xrefstyle='select: title'/> simply returns a pointer to these 8 bytes; it does not actually read any data into the input buffer. </para> <para> 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 <xref linkend='IceReadCompleteMessage' xrefstyle='select: title'/> 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 <xref linkend='IceReadMessageHeader' xrefstyle='select: title'/> and <xref linkend='IceReadData' xrefstyle='select: title'/> </para> <funcsynopsis id='IceReadCompleteMessage'> <funcprototype> <funcdef><function> IceReadCompleteMessage</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> header_size</parameter></paramdef> <paramdef><C_data_type><parameter> *pmsg</parameter></paramdef> <paramdef>char<parameter> *pdata</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>header_size</emphasis></term> <listitem> <para>The size of the message header (in bytes).</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'><C_data_type></emphasis></term> <listitem> <para>The actual C data type of the message header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pmsg</emphasis></term> <listitem> <para>This pointer is set to the message header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pdata</emphasis></term> <listitem> <para> This pointer is set to the variable length data of the message. </para> </listitem> </varlistentry> </variablelist> <para> If the ICE input buffer has sufficient space, <xref linkend='IceReadCompleteMessage' xrefstyle='select: title'/> 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. </para> <para> After calling <xref linkend='IceReadCompleteMessage' xrefstyle='select: title'/> and processing the message, <xref linkend='IceDisposeCompleteMessage' xrefstyle='select: title'/> should be called. </para> <funcsynopsis id='IceDisposeCompleteMessage'> <funcprototype> <funcdef><function> IceDisposeCompleteMessage</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>char<parameter> *pdata</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pdata</emphasis></term> <listitem> <para> The pointer to the variable length data returned in <xref linkend='IceReadCompleteMessage' xrefstyle='select: title'/> </para> </listitem> </varlistentry> </variablelist> <para> If a buffer had to be allocated to hold the variable length data (because it did not fit in the ICE input buffer), it is freed here by ICElib. </para> <funcsynopsis id='IceReadMessageHeader'> <funcprototype> <funcdef><function> IceReadMessageHeader</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> header_size</parameter></paramdef> <paramdef><C_data_type><parameter> *pmsg</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>header_size</emphasis></term> <listitem> <para>The size of the message header (in bytes).</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'><C_data_type></emphasis></term> <listitem> <para>The actual C data type of the message header.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pmsg</emphasis></term> <listitem> <para>This pointer is set to the message header.</para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceReadMessageHeader' xrefstyle='select: title'/> reads just the message header. The rest of the data should be read with the <xref linkend='IceReadData' xrefstyle='select: title'/> family of macros. This method of reading a message should be used when the variable length data must be read in chunks. </para> <para> To read data directly into a user supplied buffer, use <xref linkend='IceReadData' xrefstyle='select: title'/> </para> <funcsynopsis id='IceReadData'> <funcprototype> <funcdef><function> IceReadData</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *pdata</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to read.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pdata</emphasis></term> <listitem> <para>The data is read into this user supplied buffer.</para> </listitem> </varlistentry> </variablelist> <para> To read data as 16-bit quantities, use <xref linkend='IceReadData16' xrefstyle='select: title'/> </para> <funcsynopsis id='IceReadData16'> <funcprototype> <funcdef><function> IceReadData16</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>Bool<parameter> swap</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *pdata</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para> If <function>True,</function> the values will be byte swapped. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to read.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pdata</emphasis></term> <listitem> <para>The data is read into this user supplied buffer.</para> </listitem> </varlistentry> </variablelist> <para> To read data as 32-bit quantities, use <xref linkend='IceReadData32' xrefstyle='select: title'/> </para> <funcsynopsis id='IceReadData32'> <funcprototype> <funcdef><function> IceReadData32</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>Bool<parameter> swap</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> <paramdef>char<parameter> *pdata</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para> If <function>True,</function> the values will be byte swapped. </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of bytes to read.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>pdata</emphasis></term> <listitem> <para>The data is read into this user supplied buffer.</para> </listitem> </varlistentry> </variablelist> <para>To force 32-bit or 64-bit alignment, use <xref linkend='IceReadPad' xrefstyle='select: title'/> A maximum of 7 pad bytes can be specified.</para> <funcsynopsis id='IceReadPad'> <funcprototype> <funcdef><function> IceReadPad</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem> <para>A valid ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>bytes</emphasis></term> <listitem> <para>The number of pad bytes.</para> </listitem> </varlistentry> </variablelist> </sect1> </chapter> <chapter id='Error_Handling'> <title>Error Handling</title> <para>There are two default error handlers in ICElib:</para> <itemizedlist> <listitem> <para> One to handle typically fatal conditions (for example, a connection dying because a machine crashed) </para> </listitem> <listitem> <para>One to handle ICE-specific protocol errors</para> </listitem> </itemizedlist> <para> 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. </para> <para> To set the ICE error handler, use <xref linkend='IceSetErrorHandler' xrefstyle='select: title'/> </para> <funcsynopsis id='IceSetErrorHandler'> <funcprototype> <funcdef><function> IceSetErrorHandler</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>int<parameter> bytes</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>handler</emphasis></term> <listitem> <para> The ICE error handler. You should pass NULL to restore the default handler. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceSetErrorHandler' xrefstyle='select: title'/> returns the previous error handler. </para> <para> 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 <function>stderr</function> and if the severity is fatal, call <function>exit</function> with a nonzero value. If exiting is undesirable, the application should register its own error handler. </para> <para> Note that errors in other protocol domains should be handled by their respective libraries (these libraries should have their own error handlers). </para> <para> An ICE error handler has the type of <xref linkend='IceErrorHandler' xrefstyle='select: title'/> </para> <funcsynopsis id='IceErrorHandler'> <funcprototype> <funcdef>void<function> IceErrorHandler</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>Bool<parameter> swap</parameter></paramdef> <paramdef>int<parameter> offending_minor_opcode</parameter></paramdef> <paramdef>unsigned long<parameter> offending_sequence_num</parameter></paramdef> <paramdef>int<parameter> error_class</parameter></paramdef> <paramdef>int<parameter> severity</parameter></paramdef> <paramdef>IcePointer<parameter> values</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>handler</emphasis></term> <listitem> <para>The ICE connection object.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>swap</emphasis></term> <listitem> <para>A flag that indicates if the values need byte swapping.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>offending_minor_opcode</emphasis></term> <listitem> <para>The ICE minor opcode of the offending message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>offending_sequence_num</emphasis></term> <listitem> <para>The sequence number of the offending message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>error_class</emphasis></term> <listitem> <para>The error class of the offending message.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>severity</emphasis></term> <listitem> <para> <function>IceCanContinue</function> <function>IceFatalToProtocol</function> or <function>IceFatalToConnection</function> </para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>values</emphasis></term> <listitem> <para> Any additional error values specific to the minor opcode and class. </para> </listitem> </varlistentry> </variablelist> <para>The following error classes are defined at the ICE level:</para> <literallayout remap='Ds'> <function>IceBadMinor</function> <function>IceBadState</function> <function>IceBadLength</function> <function>IceBadValue</function> <function>IceBadMajor</function> <function>IceNoAuth</function> <function>IceNoVersion</function> <function>IceSetupFailed</function> <function>IceAuthRejected</function> <function>IceAuthFailed</function> <function>IceProtocolDuplicate</function> <function>IceMajorOpcodeDuplicate</function> <function>IceUnknownProtocol</function> </literallayout> <para> For further information, see the <emphasis remap='I'>Inter-Client Exchange Protocol</emphasis> standard. </para> <para> To handle fatal I/O errors, use <xref linkend='IceSetIOErrorHandler' xrefstyle='select: title'/> </para> <funcsynopsis id='IceSetIOErrorHandler'> <funcprototype> <funcdef>IceIOErrorHandler<function> IceSetIOErrorHandler</function></funcdef> <paramdef>IceIOErrorHandler<parameter> handler</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>handler</emphasis></term> <listitem> <para> The I/O error handler. You should pass NULL to restore the default handler. </para> </listitem> </varlistentry> </variablelist> <para> <xref linkend='IceSetIOErrorHandler' xrefstyle='select: title'/> returns the previous IO error handler. </para> <para> An ICE I/O error handler has the type of <xref linkend='IceIOErrorHandler' xrefstyle='select: title'/> </para> <funcsynopsis id='IceIOErrorHandler'> <funcprototype> <funcdef>void<function> IceIOErrorHandler</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> </variablelist> <para> There are two ways of handling IO errors in ICElib:</para> <itemizedlist> <listitem> <para> In the first, the IO error handler does whatever is necessary to respond to the IO error and then returns, but it does not call <xref linkend='IceCloseConnection' xrefstyle='select: title'/> The ICE connection is given a "bad IO" status, and all future reads and writes to the connection are ignored. The next time <xref linkend='IceProcessMessages' xrefstyle='select: title'/> is called it will return a status of <function>IceProcessMessagesIOError</function> At that time, the application should call <xref linkend='IceCloseConnection' xrefstyle='select: title'/> </para> </listitem> <listitem> <para> In the second, the IO error handler does call <xref linkend='IceCloseConnection' xrefstyle='select: title'/> and then uses the <function>longjmp</function> call to get back to the application's main event loop. The <function>setjmp</function> and <function>longjmp</function> calls may not work properly on all platforms, and special care must be taken to avoid memory leaks. Therefore, this second model is less desirable. </para> </listitem> </itemizedlist> <para> Before the application I/O error handler is invoked, protocol libraries that were interested in being notified of I/O errors will have their <xref linkend='IceIOErrorProc' xrefstyle='select: title'/> handlers invoked. This handler is set up in the protocol registration functions (see <xref linkend='IceRegisterForProtocolSetup' xrefstyle='select: title'/> and <xref linkend='IceRegisterForProtocolReply' xrefstyle='select: title'/> and could be used to clean up state specific to the protocol. </para> <funcsynopsis id='IceIOErrorProc'> <funcprototype> <funcdef>void<function> IceIOErrorProc</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> </variablelist> <para> Note that every <xref linkend='IceIOErrorProc' xrefstyle='select: title'/> 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. </para> </chapter> <chapter id='Multi_Threading_Support'> <title>Multi-Threading Support</title> <para>To declare that multiple threads in an application will be using the ICE library, use <function>IceInitThreads</function></para> <literallayout remap='FD'> Status IceInitThreads() </literallayout> <para>The <function>IceInitThreads</function> function must be the first ICElib function a multi-threaded program calls. It must complete before any other ICElib call is made. <function>IceInitThreads</function> returns a nonzero status if and only if it was able to initialize the threads package successfully. It is safe to call <function>IceInitThreads</function> more than once, although the threads package will only be initialized once.</para> <para>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:</para> <funcsynopsis id='IceLockConn'> <funcprototype> <funcdef>void<function> IceLockConn</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <funcsynopsis id='IceUnlockConn'> <funcprototype> <funcdef>void<function> IceUnlockConn</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> </variablelist> <para>To keep an ICE connection locked across several ICElib calls, applications use <xref linkend='IceAppLockConn' xrefstyle='select: title'/> and <xref linkend='IceAppUnlockConn' xrefstyle='select: title'/></para> <funcsynopsis id='IceAppLockConn'> <funcprototype> <funcdef>void<function> IceAppLockConn</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> </variablelist> <para>The <xref linkend='IceAppLockConn' xrefstyle='select: title'/> function completely locks out other threads using the connection until <xref linkend='IceAppUnlockConn' xrefstyle='select: title'/> is called. Other threads attempting to use ICElib calls on the connection will block. If the program has not previously called <function>IceInitThreads</function> <xref linkend='IceAppLockConn' xrefstyle='select: title'/> has no effect.</para> <funcsynopsis id='IceAppUnlockConn'> <funcprototype> <funcdef>void<function> IceAppUnlockConn</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> </variablelist> <para>The <xref linkend='IceAppUnlockConn' xrefstyle='select: title'/> function allows other threads to complete ICElib calls on the connection that were blocked by a previous call to <xref linkend='IceAppLockConn' xrefstyle='select: title'/> from this thread. If the program has not previously called <function>IceInitThreads</function> <xref linkend='IceAppUnlockConn' xrefstyle='select: title'/> has no effect.</para> </chapter> <chapter id='Miscellaneous_Functions'> <title>Miscellaneous Functions</title> <para>To allocate scratch space (for example, when generating messages with variable data), use <function>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.</para> <funcsynopsis id='IceAllocScratch'> <funcprototype> <funcdef>char<function> *IceAllocScratch</function></funcdef> <paramdef>IceConn<parameter> ice_conn</parameter></paramdef> <paramdef>unsigned long<parameter> size</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>ice_conn</emphasis></term> <listitem><para>The ICE connection object.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>size</emphasis></term> <listitem><para>The number of bytes required.</para></listitem> </varlistentry> </variablelist> <para>Note that the memory returned by <function>IceAllocScratch</function> should not be freed by the caller. The ICE library will free the memory when the ICE connection is closed.</para> </chapter> <chapter id='Acknowledgements'> <title>Acknowledgements</title> <para> 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, Jim VanGilder, and Mike Wexler. </para> </chapter> <appendix id="authentication_utility_functions"> <title>Authentication Utility Functions</title> <para> As discussed in this document, the means by which authentication data is obtained by the ICE library (for <function>ConnectionSetup</function> messages or <function>ProtocolSetup</function> messages) is implementation-dependent.† <footnote remap='FS'> <para>The X Consortium's ICElib implementation assumes the presence of an ICE authority file. </para></footnote> </para> <para> This appendix describes some utility functions that manipulate an ICE authority file. The authority file can be used to pass authentication data between clients. </para> <para>The basic operations on the .ICEauthority file are:</para> <itemizedlist> <listitem> <para>Get file name</para> </listitem> <listitem> <para>Lock</para> </listitem> <listitem> <para>Unlock</para> </listitem> <listitem> <para>Read entry</para> </listitem> <listitem> <para>Write entry</para> </listitem> <listitem> <para>Search for entry</para> </listitem> </itemizedlist> <para> These are fairly low-level operations, and it is expected that a program, like "iceauth", would exist to add, remove, and display entries in the file. </para> <para> In order to use these utility functions, the <<symbol role='Pn'>X11/ICE/ICEutil.h</symbol>> header file must be included. </para> <para> An entry in the .ICEauthority file is defined by the following data structure: </para> <literallayout class="monospaced"> typedef struct { char *protocol_name; unsigned short protocol_data_length; char *protocol_data; char *network_id; char *auth_name; unsigned short auth_data_length; char *auth_data; } IceAuthFileEntry; </literallayout> <para> The protocol_name member is either "ICE" for connection setup authentication or the subprotocol name, such as "XSMP". For each entry, protocol specific data can be specified in the protocol_data member. This can be used to search for old entries that need to be removed from the file. </para> <para> The network_id member is the network ID of the client accepting authentication (for example, the network ID of a session manager). A network ID has the following form: </para> <informaltable frame='none'> <?dbfo keep-together="always" ?> <tgroup cols='2' align='left' colsep='0' rowsep='0'> <colspec colname='c1' colwidth='1.0*'/> <colspec colname='c2' colwidth='2.0*'/> <tbody> <row> <entry>tcp/<hostname>:<portnumber></entry> <entry>or</entry> </row> <row> <entry>decnet/<hostname>::<objname></entry> <entry>or</entry> </row> <row> <entry>local/<hostname>:<path></entry> <entry></entry> </row> </tbody> </tgroup> </informaltable> <para> The auth_name member is the name of the authentication method. The auth_data member is the actual authentication data, and the auth_data_length member is the number of bytes in the data. </para> <para> To obtain the default authorization file name, use <function>IceAuthFileName</function> </para> <literallayout remap='FD'> char *IceAuthFileName() </literallayout> <para> If the ICEAUTHORITY environment variable if set, this value is returned. Otherwise, the default authorization file name is $HOME/.ICEauthority. This name is statically allocated and should not be freed. </para> <para> To synchronously update the authorization file, the file must be locked with a call to <xref linkend='IceLockAuthFile' xrefstyle='select: title'/> This function takes advantage of the fact that the <function>link</function> system call will fail if the name of the new link already exists. </para> <funcsynopsis id='IceLockAuthFile'> <funcprototype> <funcdef>int<function> IceLockAuthFile</function></funcdef> <paramdef>char<parameter> *file_name</parameter></paramdef> <paramdef>int<parameter> retries</parameter></paramdef> <paramdef>int<parameter> timeout</parameter></paramdef> <paramdef>long<parameter> dead</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>file_name</emphasis></term> <listitem><para>The authorization file to lock.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>retries</emphasis></term> <listitem> <para>The number of retries.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>timeout</emphasis></term> <listitem> <para>The number of seconds before each retry.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>dead</emphasis></term> <listitem> <para> If a lock already exists that is the specified dead seconds old, it is broken. A value of zero is used to unconditionally break an old lock. </para> </listitem> </varlistentry> </variablelist> <para>One of three values is returned:</para> <itemizedlist> <listitem> <para> <function>IceAuthLockSuccess</function> - the lock succeeded. </para> </listitem> <listitem> <para> <function>IceAuthLockError</function> - a system error occurred, and <function>errno</function> may prove useful. </para> </listitem> <listitem> <para> <function>IceAuthLockTimeout</function> - the specified number of retries failed. </para> </listitem> </itemizedlist> <para> To unlock an authorization file, use <xref linkend='IceUnlockAuthFile' xrefstyle='select: title'/> </para> <funcsynopsis id='IceUnlockAuthFile'> <funcprototype> <funcdef>int<function> IceUnlockAuthFile</function></funcdef> <paramdef>char<parameter> *file_name</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>file_name</emphasis></term> <listitem><para>The authorization file to unlock.</para></listitem> </varlistentry> </variablelist> <para> To read the next entry in an authorization file, use <function>IceReadAuthFileEntry</function> </para> <funcsynopsis id='IceReadAuthFileEntry'> <funcprototype> <funcdef>IceAuthFileEntry<function> *IceReadAuthFileEntry</function></funcdef> <paramdef>FILE<parameter> *auth_file</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>auth_file</emphasis></term> <listitem><para>The authorization file.</para></listitem> </varlistentry> </variablelist> <para> Note that it is the responsibility of the application to open the file for reading before calling this function. If an error is encountered, or there are no more entries to read, NULL is returned. </para> <para> Entries should be free with a call to <xref linkend='IceFreeAuthFileEntry' xrefstyle='select: title'/> </para> <para> To write an entry in an authorization file, use <xref linkend='IceWriteAuthFileEntry' xrefstyle='select: title'/> </para> <funcsynopsis id='IceWriteAuthFileEntry'> <funcprototype> <funcdef>Status<function> IceWriteAuthFileEntry</function></funcdef> <paramdef>FILE<parameter> *auth_file</parameter></paramdef> <paramdef>IceAuthFileEntry<parameter> *entry</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>auth_file</emphasis></term> <listitem><para>The authorization file.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>entry</emphasis></term> <listitem><para>The entry to write.</para></listitem> </varlistentry> </variablelist> <para> Note that it is the responsibility of the application to open the file for writing before calling this function. The function returns a nonzero status if the operation was successful. </para> <para> To search the default authorization file for an entry that matches a given protocol_name/network_id/auth_name tuple, use <function>IceGetAuthFileEntry</function> </para> <funcsynopsis id='IceGetAuthFileEntry'> <funcprototype> <funcdef>IceAuthFileEntry<function> *IceGetAuthFileEntry</function></funcdef> <paramdef>const char *<parameter>protocol_name</parameter></paramdef> <paramdef>const char *<parameter>network_id</parameter></paramdef> <paramdef>const char *<parameter>auth_name</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>auth_file</emphasis></term> <listitem><para>The name of the protocol to search on.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>network_id</emphasis></term> <listitem> <para>The network ID to search on.</para> </listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>auth_name</emphasis></term> <listitem> <para>The authentication method to search on.</para> </listitem> </varlistentry> </variablelist> <para> If <function>IceGetAuthFileEntry</function> fails to find such an entry, NULL is returned. </para> <para> To free an entry returned by <function>IceReadAuthFileEntry</function> or <function>IceGetAuthFileEntry</function> use <xref linkend='IceFreeAuthFileEntry' xrefstyle='select: title'/> </para> <funcsynopsis id='IceFreeAuthFileEntry'> <funcprototype> <funcdef>void<function> IceFreeAuthFileEntry</function></funcdef> <paramdef>IceAuthFileEntry<parameter> *entry</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>entry</emphasis></term> <listitem><para>The entry to free.</para></listitem> </varlistentry> </variablelist> </appendix> <appendix id="mit_magic_cookie_1_authentication"> <title>MIT-MAGIC-COOKIE-1 Authentication</title> <para>The X Consortium's ICElib implementation supports a simple MIT-MAGIC-COOKIE-1 authentication scheme using the authority file utilities described in Appendix A.</para> <para>In this model, an application, such as a session manager, obtains a magic cookie by calling <function>IceGenerateMagicCookie</function> and then stores it in the user's local .ICEauthority file so that local clients can connect. In order to allow remote clients to connect, some remote execution mechanism should be used to store the magic cookie in the user's .ICEauthority file on a remote machine.</para> <para>In addition to storing the magic cookie in the .ICEauthority file, the application needs to call the <xref linkend='IceSetPaAuthData' xrefstyle='select: title'/> function in order to store the magic cookie in memory. When it comes time for the MIT-MAGIC-COOKIE-1 authentication procedure to accept or reject the connection, it will compare the magic cookie presented by the requestor to the magic cookie in memory.</para> <funcsynopsis id='IceGenerateMagicCookie'> <funcprototype> <funcdef>char<function> *IceGenerateMagicCookie</function></funcdef> <paramdef>int<parameter> length</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>length</emphasis></term> <listitem><para>The desired length of the magic cookie.</para></listitem> </varlistentry> </variablelist> <para>The magic cookie returned will be null-terminated. If memory can not be allocated for the magic cookie, the function will return NULL. Otherwise, the magic cookie should be freed with a call to <function>free</function></para> <para>To store the authentication data in memory, use <xref linkend='IceSetPaAuthData' xrefstyle='select: title'/> Currently, this function is only used for MIT-MAGIC-COOKIE-1 authentication, but it may be used for additional authentication methods in the future.</para> <funcsynopsis id='IceSetPaAuthData'> <funcprototype> <funcdef>void<function> IceSetPaAuthData</function></funcdef> <paramdef>int<parameter> num_entries</parameter></paramdef> <paramdef>IceAuthDataEntry<parameter> *entries</parameter></paramdef> </funcprototype> </funcsynopsis> <variablelist remap='IP'> <varlistentry> <term><emphasis remap='I'>num_entries</emphasis></term> <listitem><para>The number of authentication data entries.</para></listitem> </varlistentry> <varlistentry> <term><emphasis remap='I'>entries</emphasis></term> <listitem><para>The list of authentication data entries.</para></listitem> </varlistentry> </variablelist> <para>Each entry has associated with it a protocol name (for example, "ICE" for ICE connection setup authentication, "XSMP" for session management authentication), a network ID for the "accepting" client, an authentication name (for example, MIT-MAGIC-COOKIE-1), and authentication data. The ICE library will merge these entries with previously set entries, based on the (protocol_name, network_id, auth_name) tuple.</para> <literallayout class="monospaced"> typedef struct { char *protocol_name; char *network_id; char *auth_name; unsigned short auth_data_length; char *auth_data; } IceAuthDataEntry; </literallayout> </appendix> </book> PK t��[���� � ChangeLognu �[��� commit 8e6a14c63d6b73cde87cb331439f2a4d19cba5b9 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Jul 14 10:37:25 2019 -0700 libICE 1.0.10 Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit b6aad584c1dc278364c295165512b5f5b98c173e Author: Olivier Fourdan <ofourdan@redhat.com> Date: Thu Apr 11 09:05:15 2019 +0200 cleanup: Separate variable assignment and test Assigning and testing a value in a single statement hinders code clarity and may confuses static code analyzers. Separate the assignment and the test for clarity. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> commit 772e5b0fdfc9dbd8bec070bd0c4c7eb5565df2ee Author: Olivier Fourdan <ofourdan@redhat.com> Date: Wed Apr 10 11:15:11 2019 +0200 _IceRead: Avoid possible use-after-free `_IceRead()` gets called from multiple places which do not expect the connection to be freed. Do not free the connection data in `_IceRead()` to avoid potential use-after-free issue in the various callers. The connection data will be freed eventually in `ProcessWantToClose()`, so not freeing it in `_IceRead()` should not introduce an memory leak. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> commit 1493beba2aa03bdadeed8b4fa5d424df6e113071 Author: Olivier Fourdan <ofourdan@redhat.com> Date: Wed Apr 10 11:01:31 2019 +0200 IceListenForWellKnownConnections: Fix memleak The function `_IceTransMakeAllCOTSServerListeners` allocates memory for `transConns` which is leaked in case of error. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> commit a67a477eefdc93c32fa82da6ff0b4e69dd4c2ccb Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Mar 24 15:29:34 2019 -0700 IceWritePad: always use zero values for pad bytes Previously it would just bump the pointer in the buffer leaving whatever values were previously there in place. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 2318ace3340009c44e78eab094f159f0e0b4a197 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Mar 24 14:36:10 2019 -0700 IceOpenConnection: check for malloc failure on connect_to_you too Fixes: https://gitlab.freedesktop.org/xorg/lib/libice/issues/4 Reported-by: mahendra <mahendra.n@samsung.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit b484311c929a1b64966d89da92fafce7263006e1 Author: Allison Lortie <desrt@desrt.ca> Date: Tue Jun 14 16:09:46 2016 -0400 authutil: support $XDG_RUNTIME_DIR/ICEauthority If we find that $XDG_RUNTIME_DIR is set (and $ICEAUTHORITY is not), then the ICEauthority file is stored in the XDG_RUNTIME_DIR instead of the home directory, and without a leading dot. https://bugs.freedesktop.org/show_bug.cgi?id=49173 Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 48ed5e04b5a8ba64dcfeea090cf3a32d3087b749 Author: Allison Lortie <desrt@desrt.ca> Date: Tue Jun 14 16:08:21 2016 -0400 authutil: fix an out-of-bounds access There is a theoretical edge case where the $HOME environment variable could be set to the empty string. IceAuthFileName() unconditionally checks index 1 of this string, which is out of bounds. Fix that up by rejecting empty strings in the same way as we reject NULL. https://bugs.freedesktop.org/show_bug.cgi?id=49173 Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 468b83ec4810b4ea2373182b5801f998f3dcd471 Author: Tobias Stoeckmann <tobias@stoeckmann.org> Date: Mon Jul 30 20:50:58 2018 +0200 Always terminate strncpy results. The function strncpy does not guarantee to append a terminating NUL character to the destination. This patch merges libSM's way of handling this issue into libICE. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 1cc4ae8648590f04557a20c8d88d39cef7fe8119 Author: walter harms <wharms@bfs.de> Date: Thu Sep 7 18:52:13 2017 +0200 iceauth.c: FIX warning: unused variable 'ret' in 'arc4random_buf' commit ff5e59f32255913bb1cdf51441b98c9107ae165b left ret outside the #if causing a gcc warning: In function 'arc4random_buf': iceauth.c:89:13: warning: unused variable 'ret' [-Wunused-variable] fixed by moving #if 1 up Signed-off-by: Walter Harms <wharms@bfs.de> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit ccbcae7d3409789bf346ca35963264d064f54cba Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Fri Dec 7 19:29:55 2018 -0800 Update configure.ac bug URL for gitlab migration Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit e72ca90879db149bbee6232dd78a565e630e917d Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Nov 18 21:48:59 2018 -0800 Update README for gitlab migration Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit dc73ec034c9083b8c7d980e80eb6d4c88bcfaa51 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Nov 10 13:13:45 2018 -0800 Remove obsolete B16 & B32 tags in struct definitions Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit f66955f7250d7c150dfb97862878acc2222781e5 Author: walter harms <wharms@bfs.de> Date: Fri Sep 8 20:03:03 2017 +0200 make IceProtocolShutdown() more readable I found IceProtocolShutdown() hard to read only to find that was it does it aktually very simple. So i rearranged the code to make it more readable. Signed-off-by: Walter Harms <wharms@bfs.de> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> [Emil Velikov: whitespace fixes] Signed-off-by: Emil Velikov <emil.velikov@collabora.com> commit 936dcaac07f7db569ed91a34e0a4b5944aac205f Author: walter harms <wharms@bfs.de> Date: Fri Sep 8 19:59:17 2017 +0200 Drop NULL check prior to free() free() can handle NULL just fine - remove the check. Signed-off-by: Walter Harms <wharms@bfs.de> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> commit 43644931cb9cb5cc92391f6f5431535b9b7a3f24 Author: Eric Engestrom <eric.engestrom@imgtec.com> Date: Fri Jul 7 11:23:48 2017 +0100 Make sure string is never NULL `error_message` is passed in to strncpy() without any check, which doesn't handle NULL itself, so let's make it a valid empty string in cases where it was NULL. Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com> Acked-by: Walter Harms <wharms@bfs.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> commit e8c21056134498c49733f6baf572ffbb051ed886 Author: Eric Engestrom <eric.engestrom@imgtec.com> Date: Fri Jul 7 11:23:47 2017 +0100 Make sure error_message is a free-able string Similar to the previous commit, assigning a static string would crash upon freeing. Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com> Acked-by: Walter Harms <wharms@bfs.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> commit 7a7844bf5ade915268fe7f9b292908c6cd75f3ba Author: Eric Engestrom <eric.engestrom@imgtec.com> Date: Fri Jul 7 11:23:46 2017 +0100 Make sure errorStr is a free-able string If the `errorClass` isn't handled by the switch, `errorStr`'s initial value would be a pointer to some static memory with an empty string, and freeing it would most likely crash. Let's set it to NULL instead, as is done in other similar places. Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com> Acked-by: Walter Harms <wharms@bfs.de> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> commit 7ef9680caa8c223a09beb637e26fd3471128e6ba Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Sun May 8 09:19:36 2016 +0100 configure.ac: set TRANS_CLIENT/SERVER Similar to ICE_t just set the define globally and remove the multiple definitions throughout the tree Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC) commit ab64a947b5de5b778f31ede9cfce386566023a14 Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Sun May 8 09:19:35 2016 +0100 Kill off local ICE_t definitions Already defined at global scale in configure.ac Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC) commit f4c00d345edf3dad5893b50ff0ae7cd3e0cfd780 Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Sun May 8 09:19:34 2016 +0100 Remove unneeded ^L symbols. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC) commit d603d7d7d989c4ff1094810e9fcf2a29bc00bb0c Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Sun May 8 09:19:33 2016 +0100 Kill off Time_t macro Analogous to previous commit, including the megacommit that removed the need for it. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC) commit 82250f26fc76d7b7574cfd472646a98e325d944a Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Sun May 8 09:19:32 2016 +0100 Kill off Strstr macro Directly use the strstr function as opposed to wrapping it in a macro. The latter is no longer needed as of commit 72e353567f8927996a26e72848d86f692c3f0737 Author: Kaleb Keithley <kaleb@freedesktop.org> Date: Fri Nov 14 16:48:46 2003 +0000 XFree86 4.3.0.1 Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (IRC) commit ff5e59f32255913bb1cdf51441b98c9107ae165b Author: Benjamin Tissoires <benjamin.tissoires@gmail.com> Date: Tue Apr 4 19:12:53 2017 +0200 Use getentropy() if arc4random_buf() is not available This allows to fix CVE-2017-2626 on Linux platforms without pulling in libbsd. The libc getentropy() is available since glibc 2.25 but also on OpenBSD. For Linux, we need at least a v3.17 kernel. If the recommended arc4random_buf() function is not available, emulate it by first trying to use getentropy() on a supported glibc and kernel. If the call fails, fall back to the current (partly vulnerable) code. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> commit 1746abbb1ae1c41ba29c14895c5bd3f1334faef5 Author: Mihail Konev <k.mvc@ya.ru> Date: Thu Jan 26 13:52:49 2017 +1000 autogen: add default patch prefix Signed-off-by: Mihail Konev <k.mvc@ya.ru> commit 3aa14db63fefb7634b1bd4370e33ba14c4ea90ae Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Mon Mar 9 12:00:52 2015 +0000 autogen.sh: use quoted string variables Place quotes around the $srcdir, $ORIGDIR and $0 variables to prevent fall-outs, when they contain space. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> commit d41c57eaa0c1474acf0a6fb271f22106e3070016 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Tue Jan 24 10:32:07 2017 +1000 autogen.sh: use exec instead of waiting for configure to finish Syncs the invocation of configure with the one from the server. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> commit ac4bb20e74e064b219de70e9b54516a921fdb7c3 Author: Tobias Stoeckmann <tobias@stoeckmann.org> Date: Tue Nov 22 20:13:29 2016 +0100 Fix use after free on subsequent calls The function IceAuthFileName is vulnerable to a use after free. The flaw can be triggered by calling the function three times: - First call succeeds and stores the path in buf, a dynamically allocated buffer with size bsize. - Second call fails due to out of memory. It frees buf, but keeps the old size in bsize. - Third call only checks if bsize is large enough. Then it uses buf without allocating it again -- the use after free happens. In order to exploit this, an attacker must change environment variables between each call, namely ICEAUTHORITY or HOME. It also takes subsequent calls. Due to these limitations, I don't consider this to be of high priority. Reviewed-by: Matthieu Herrb <matthieu@herrb.eu> commit b1720edc9b9f3e7a05caa3fcd81761e5818ea255 Author: Remko van der Vossen <bugs@yuugen.jp> Date: Sun Jul 19 08:34:11 2015 -0700 Bug 90616 - libICE build fails on array bounds check https://bugs.freedesktop.org/show_bug.cgi?id=90616 Recent versions of gcc have array bounds checking turned on by default, this leads to build failures of libICE. As the _IceVersionCount variable in ICElibint.h is not declared const the compiler cannot assume that the nested for loop in ProcessConnectionSetup stays within bounds. The simple fix is of course to change the declarations of _IceVersionCount, _IceVersions, and the local variable myVersionCount to const declarations. Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 8a511dad53774693ed818d54d7896e1663942b18 Author: Jon TURNEY <jon.turney@dronecode.org.uk> Date: Sat Sep 13 17:13:44 2014 +0100 Include unistd.h for getpid() Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk> Reviewed-by: David Macek <david.macek.0@gmail.com> commit fd22b62ae6380ddb00fa4c750f5ce175d2a6e76f Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Sep 14 13:08:17 2014 -0700 spec: Convert troff \*Q..\*U to DocBook <quote>...</quote> Reported-by: Jasper St. Pierre <jstpierre@mecheye.net> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net> commit 0dfab4253e26d5c6e5f058126eb5e9f7a7732ae8 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Fri Jun 6 18:28:28 2014 -0700 libICE 1.0.9 Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 9fb6ba03d7183ae06644f8a747fdb99b970d65fc Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Tue Dec 24 09:35:02 2013 -0800 Delete unused name variable in register.c Found by cppcheck 1.62: [src/register.c:84]: (style) Variable 'name' is assigned a value that is never used. [src/register.c:182]: (style) Variable 'name' is assigned a value that is never used. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit c5060918164168c0a4f737b76e92df3c03356dc6 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Tue Dec 24 09:18:17 2013 -0800 Free iceConn->connection_string when unwinding after malloc fails Found by cppcheck 1.62: [src/accept.c:113]: (error) Memory leak: iceConn.connection_string Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 80f62c54fbd50a3bbdf9c37258525098c9117830 Author: Matthieu Herrb <matthieu.herrb@laas.fr> Date: Thu Aug 29 22:18:14 2013 +0200 Use arc4random when available to produce the auth cookie. arc4random() and associated functions can be found in libbsd on GNU/Linux systems. Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 2312ee00402088307e69589c3d12529b5232df66 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Aug 8 23:01:30 2013 -0700 Make STORE_STRING cast strlen result to CARD16 when storing in CARD16 Clears a number of clang warnings of the form: connect.c:328:6: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'CARD16' (aka 'unsigned short') [-Wconversion] STORE_STRING (pData, _IceAuthNames[i]); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./ICElibint.h:173:19: note: expanded from macro 'STORE_STRING' CARD16 _len = strlen (_string); \ ~~~~ ^~~~~~~~~~~~~~~~ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 6d6aa84dc6acb2daa3ef7e20942c38a1416bf543 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Aug 8 22:58:46 2013 -0700 Cast assignments in IceErrorHeader() macro Clears many clang warnings about implicit conversions losing integer precision, such as from storing ints into CARD8 or CARD16. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 9450bb648ef98efd6f08ea7d14ab8b9ea6e7bb54 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Aug 8 22:47:41 2013 -0700 Make write_string call write_counted_string instead of copying it Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 84153eee4db318cd897c464e70cb9f8bc8e469f6 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Aug 8 22:37:09 2013 -0700 Mark input arguments to write_string functions as const Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 9a74512ffdc1628f1b87d2191439915c63b9104f Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Aug 8 22:31:41 2013 -0700 Stop casting return values from malloc Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 4033226105fa861ab5f0276850afc24c0fa45406 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Aug 8 22:17:27 2013 -0700 Get rid of casts to (char *) in calls to free() Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 10c30ae6a7df1a7c352a1d611a313dffcaa42082 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Jul 20 14:48:33 2013 -0700 Convert remaining sprintf() call to snprintf() Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 0a94633e3d805ca477fba6b7acb673d055a3f43d Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Jul 20 14:46:09 2013 -0700 Convert strcpy/strcat pairs to snprintf calls Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 0d276835222eeb57de56f56cd9e12611b1d30466 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Jul 20 14:35:11 2013 -0700 Fix some clang warnings about integer sign/size conversions Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit bb3d8a7767cf260b97c7e019e4fec0ee7d7b65a8 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Jul 20 14:24:04 2013 -0700 unifdef WORD64 Remove leftover remnants of CRAY support, which still had some functions consisting solely of /* NOT IMPLEMENTED YET */ comments. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 9561eca1ad28afee6dcd0aebea3dd20a154ec481 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Jul 18 00:36:28 2013 -0700 Constify filename argument to IceLockAuthFile & IceUnlockAuthFile Needed to fix const string warnings in iceauth - functions already copy provided arguments to temporary local buffer for modifications. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> commit 1b1cf8072b2559e15ac440d5484a29a81d6918c6 Author: Colin Walters <walters@verbum.org> Date: Wed Jan 4 17:37:06 2012 -0500 autogen.sh: Implement GNOME Build API http://people.gnome.org/~walters/docs/build-api.txt Signed-off-by: Adam Jackson <ajax@redhat.com> commit 5e784ca7f37823e62733765371c0b8ed1c58e5aa Author: Adam Jackson <ajax@redhat.com> Date: Tue Jan 15 14:28:48 2013 -0500 configure: Remove AM_MAINTAINER_MODE Signed-off-by: Adam Jackson <ajax@redhat.com> commit e1677ce019219ac164d99f1e04f17caf16fc785a Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Fri Jan 4 19:32:08 2013 -0800 unifdef -U__UNIXOS2__ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit f166e8bbf16ec214fefdcf02ce81f80442899cb7 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Fri Mar 2 19:59:50 2012 -0800 libICE 1.0.8 Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit c87ecd959d61ae97d8a2bd82efc761bb3e299061 Author: Matt Dew <marcoz@osource.org> Date: Mon Jan 9 21:25:18 2012 -0700 informaltable cleanup On certain tables, add top and bottom borders to table header and a bottom border to the table. This matches what those tables in the old pdfs looked like. the <?dbfo keep-together='always'> prevents tables from splitting across pages. Useful for tiny tables. Converting the colwidth to a floating point, IE, 1* -> 1.0* cleans up these build errors: WARNING: table-layout="fixed" and column-width unspecified => falling back to proportional-column-width(1) Signed-off-by: Matt Dew <marcoz@osource.org> commit 8b4321a37a9fa2ad24bf87afabba6b08dcfded12 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Nov 24 12:42:36 2011 -0800 Plug minor memory leak in unusual path through ProcessConnectionSetup Error: Memory leak (CWE 401) Memory leak of pointer 'release' allocated with malloc((_len + 1)) at line 1100 of src/process.c in function 'ProcessConnectionSetup'. 'release' allocated at line 920 with malloc((_len + 1)). release leaks when _i >= hisAuthCount at line 925 and i >= _IceAuthCount at line 973 and found != 0 at line 998 and status != 0 at line 1053 and status != 1 at line 1070 and accept_setup_now == 0 at line 1082 and i >= hisAuthCount at line 1093. Memory leak of pointer 'vendor' allocated with malloc((_len + 1)) at line 1100 of src/process.c in function 'ProcessConnectionSetup'. 'vendor' allocated at line 919 with malloc((_len + 1)). vendor leaks when _i >= hisAuthCount at line 925 and i >= _IceAuthCount at line 973 and found != 0 at line 998 and status != 0 at line 1053 and status != 1 at line 1070 and accept_setup_now == 0 at line 1082 and i >= hisAuthCount at line 1093. [ This bug was found by the Parfait 0.3.7 bug checking tool. For more information see http://labs.oracle.com/projects/parfait/ ] Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit caf9e3393d5d517ea129392d001a2c46a7c1f325 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Nov 19 00:26:29 2011 -0800 Constify protocol, vendor & release string args to IceRegisterForProtocol* Needed to resolve gcc -Wwrite-strings warnings in callers. These functions only pass the strings to strcmp before calling strdup to make their own private copy for storing away. While fixing the API docs to match, also fix them to match the existing function prototypes, where there were several errors before (including just plain missing most of the args to IceRegisterForProtocolReply). Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit 59c1555dff34804c78c7e7443ad13f27300927eb Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Wed Nov 9 22:07:34 2011 -0800 Remove ancient workaround for System V/386 Release 4.2 compiler bug Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matthieu Herrb <matthieu.herrb@laas.fr> Reviewed-by: walter <wharms@bfs.de> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit bec4e9c9089fa4cc5a50fc513a3544cf6fd59bf1 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Wed Nov 9 22:06:36 2011 -0800 Fix gcc -Wwrite-strings warnings in process.c Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit ffa659dd6dd1fb8847bfdcc5e1e2be353b6395b6 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Wed Nov 9 21:37:48 2011 -0800 Fix gcc -Wwrite-strings warnings in AuthNames handling Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit 902a52ea9d7b6e6f56f7023009859072854a0fc7 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Wed Nov 9 21:55:17 2011 -0800 constify arguments to IceGetAuthFileEntry Needed to clear gcc -Wwrite-strings warnings in callers Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit 9ff1f97e46903f8f83363f07cf021989bfa6a9f0 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Wed Nov 9 21:43:59 2011 -0800 Fix gcc -Wwrite-strings warnings in _IceError* functions Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit e8a16534a9406d5096d9c0ea515d979c7c15e084 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Wed Nov 9 21:23:33 2011 -0800 Fix gcc -Wwrite-strings warnings in _IceDefaultErrorHandler Had to split char *str into two variables, const char *str for the string literals just being passed to fprintf etal. and char *estr for use by EXTRACT_STRING for the results of malloc calls that get written to and then freed. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit 4fbcba4ee19a49c05440861e1278bc97d29048e0 Author: Matt Dew <marcoz@osource.org> Date: Tue Oct 4 23:32:02 2011 -0600 Cleanup IDs and links in doc 1 - fix the capitalization of the ID attributes to match either the <title> or <funcdef> string it goes with. 2 - fix any <linkend>'s that were affected by 1. 3 - any <function> in the docs that has an actual funcdef, will become an olink. Signed-off-by: Matt Dew <marcoz@osource.org> commit d4e161e35335df82f412d2d2bb1ef95ff3e88401 Author: Gaetan Nadon <memsize@videotron.ca> Date: Mon Sep 19 15:34:47 2011 -0400 As of 1997, X Window System is a trademark of The Open Group. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit fc0fc948d25dfa0f6f445a3b55610ea5b864dd60 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Fri Sep 16 22:09:18 2011 -0700 Strip trailing whitespace Performed with: find * -type f | xargs perl -i -p -e 's{[ \t]+$}{}' git diff -w & git diff -b show no diffs from this change Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 22601de3f38d035eb874d4bd9f649ddd2b3f0ae2 Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Sep 11 17:20:20 2011 -0400 specs: remove <productnumber> which is not used by default This element is not rendered by default on the title. A template customization is required to display it. X Window System does not have a product number. Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 7f330738f1f5862950b3baa35ff08446093bfd4e Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Sep 11 17:06:00 2011 -0400 specs: use DocBook suggested markup for Copyrights Puts the statement on a single line, using commas to separate years --> Copyright © 1993, 1994, 1996 X Consortium As opposed to 3 double-spaced lines. Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit d68d2d2031f623a969784e702c97a07b8cd99010 Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Sep 11 16:56:21 2011 -0400 specs: remove orphan <corpname> It does not display on the title page and is redundant. No visible change on the doc. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 87c934b9b7973a814763670e2dfad0579a8dcc78 Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Sep 11 16:27:09 2011 -0400 specs: use the &fullrelvers; entity to set X11 release information Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 41f04fd8673db5c2d8e587ab2c169a694bd7528f Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Sep 11 14:13:35 2011 -0400 ice.xml: version number is 1.1, not 1.0 This is what it was before the conversion from roff to docbook. Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 9e2a596b4ff06fc9c70dfcd94506e536e351ee0b Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Sep 11 14:11:28 2011 -0400 ice.xml: fix orphan affiliation Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 1309d477a061d165345b602e122990eaab71a0d4 Author: Gaetan Nadon <memsize@videotron.ca> Date: Fri Sep 9 21:21:57 2011 -0400 ICElib doc: remove empty revision list and specify the doc version number Revision histories are not used, only 3 docs out of 63 have one. Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit e9d57773df26ad9440a49f58941b511e594605a4 Author: Gaetan Nadon <memsize@videotron.ca> Date: Thu Sep 8 20:00:00 2011 -0400 docbook.am: embed css styles inside the HTML HEAD element Rather than referring to the external xorg.css stylesheet, embed the content of the file in the html output produced. This is accomplished by using version 1.10 of xorg-xhtml.xsl. This makes the whole html docs tree much more relocatable. In addition, it eliminates xorg.css as a runtime file which makes xorg-sgml-doctools a build time only package. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit b83cbed755315f6300133f2621cbe99bdc06345a Author: Gaetan Nadon <memsize@videotron.ca> Date: Wed Sep 7 10:31:04 2011 -0400 docbook.am: global maintenance update - entities, images and olinking Adding support in libX11 for html chunking caused a reorg of docbook.am as well as the xorg-sgml-doctools masterdb for olinking. The parameter img.src.path is added for pdf images. A searchpath to the root builddir is added for local entities, if present. The docbook.am makefile hides all the details and is identical for all 22 modules having DocBook documentation. It is included by a thin Makefile.am which requires no docbook knowledge. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit f35b8b8be16f1903beed34fe23fa53d102329342 Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Jun 12 17:54:50 2011 -0400 Install xml versions of specs even if HAVE_XMLTO is false DocBook/XML input source is also a usefull output format that can be viewed with an XML viewer or editor and by some O/S help system. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 4c9cbdb1b40799121456c692d960135d741f13c7 Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Jun 5 16:27:36 2011 -0400 Install target dbs alongside generated documents This matches a change in xorg-sgml-docs whereby the masterdb will look for the target dbs into the same location as the generated documents. The target dbs are now installed alongside the generated documents. Previously they are installed in $prefix/sgml/X11/dbs alongside masterdb which has the potential of installing outside the package prefix and cause distcheck to fail when user does not have write permission in this package. Requires XORG_CHECK_SGML_DOCTOOLS(1.8) which was released 2011-06-11 commit 72d668dd2ec4db9b75973ba24f42ab49851dbc6d Author: Matt Dew <marcoz@osource.org> Date: Wed May 25 22:54:51 2011 -0600 add id attributes to funcsynopsis to allow other docs to olink to them Signed-off-by: Matt Dew <marcoz@osource.org> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Gaetan Nadon <memsize@videotron.ca> commit dd7f2beaa753541aefba499813f25de38cbd17b7 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Tue Apr 19 18:36:58 2011 -0700 IceWritePad: Zero fill pad bytes used when buffer is full Should be rarely hit, since it's only in the case where most of the message fits in the buffer, but there's not room left for the padding bytes, but better than sending uninitialized bytes off the stack when it happens. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit 663782989be82e7893c99eaa7cbe98ec25a23c38 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Tue Apr 19 18:19:19 2011 -0700 Fix reads outside array bounds in error handlers Error: Buffer overrun Read outside array bounds (CWE 125): In call to memcpy(<unknown>, &mOp, 8), (size(&mOp) < (unsigned) 8) Array size is 1 bytes at line 296 of src/error.c in function '_IceErrorMajorOpcodeDuplicate'. Error: Buffer overrun Read outside array bounds (CWE 125): In call to memcpy(<unknown>, &maj, 8), (size(&maj) < (unsigned) 8) Array size is 1 bytes at line 346 of src/error.c in function '_IceErrorBadMajor'. [ This bug was found by the Parfait 0.3.7 bug checking tool. For more information see http://labs.oracle.com/projects/parfait/ ] Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> commit daf686b7639919289b07a575a0d88efcb91d9732 Author: Gaetan Nadon <memsize@videotron.ca> Date: Wed Mar 30 20:15:07 2011 -0400 doc: xorg-sgml-doctools package at version 1.7 is required This version contains support for external references Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit fadb927532556adb471300c89de29d268aae9102 Author: Gaetan Nadon <memsize@videotron.ca> Date: Sun Feb 27 15:06:18 2011 -0500 Documentation: add Docbook external references support When writing technical documentation, it is often necessary to cross reference to other information. When that other information is not in the current document, additional support is needed, namely <olink>. A new feature with version 1.7 of xorg-sgml-doctools adds references to other documents within or outside this package. This patch adds technical support for this feature but does not change the content of the documentation as seen by the end user. Each book or article must generate a database containing the href of sections that can be referred to from another document. This database is installed in DATAROOTDIR/sgml/X11/dbs. There is a requirement that the value of DATAROOTDIR for xorg-sgml-doctools and for the package documentation is the same. This forms a virtual document tree. This database is consulted by other documents while they are being generated in order to fulfill the missing information for linking. Refer to the xorg-sgml-doctools for further technical information. Co-authored-by: Matt Dew <marcoz@osource.org> Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 483d32621c06bcba0c7aa7794633b46b151fd5bf Author: Gaetan Nadon <memsize@videotron.ca> Date: Fri Feb 25 08:58:54 2011 -0500 Docbook: change the book id to match the xml file basename This is required for the up-coming external references support. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 4852c5bb1603fb6d401fe6895d9318555a8d4523 Author: Gaetan Nadon <memsize@videotron.ca> Date: Wed Feb 2 19:13:54 2011 -0500 config: splitting ICE and XTRANS compiler options is not required Simplify configuration by using a single PKG_CHECK_MODULES statement. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 87d34a2f04c9d920da01802cd9707c8107746fa5 Author: Gaetan Nadon <memsize@videotron.ca> Date: Wed Feb 2 11:43:40 2011 -0500 config: comment, minor upgrade, quote and layout configure.ac Group statements per section as per Autoconf standard layout Quote statements where appropriate. Autoconf recommends not using dnl instead of # for comments Use AC_CONFIG_FILES to replace the deprecated AC_OUTPUT with parameters. This helps automated maintenance and release activities. Details can be found in http://wiki.x.org/wiki/NewModuleGuidelines Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 548eded10385ccc336e66dac8bbabe05f3225ec2 Author: Gaetan Nadon <memsize@videotron.ca> Date: Fri Jan 28 14:42:12 2011 -0500 config: remove unrequired AC_HEADER_STDC Autoconf says: "This macro is obsolescent, as current systems have conforming header files. New programs need not use this macro". commit 78b8e6b772685a2ed567ac2d30f96116f050dad5 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Fri Jan 7 19:29:03 2011 -0800 Resync fallback asprintf with updated version put into xrdb Fixes issues found during xrdb review on xorg-devel Also make sure <stdarg.h> is #included for varargs macros Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit dc63c253e33b1012c08cd274e6e37bf0fa87c624 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Tue Dec 21 18:28:36 2010 -0800 Add AC_USE_SYSTEM_EXTENSIONS to make asprintf() visible in GNU libc asprintf is considered a GNU extension and thus one needs to define _GNU_SOURCE before including stdio.h. Reported-by: Cyril Brulebois <kibi@debian.org> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Gaetan Nadon <memsize@videotron.ca> commit 4b4ec3aeaa7cf5f5a6490ad2ddc2b07d090214cb Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Dec 19 09:57:05 2010 -0800 Use correct string pointer in asprintf() fallback Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 308c8d3d5fbf96c1d4f313def50d4b001ac0d685 Author: Paulo Zanoni <przanoni@gmail.com> Date: Fri Dec 17 14:59:22 2010 -0200 Remove useless line from a table in specs/ice.xml This seems to be a leftover from a manpage/groff conversion. Signed-off-by: Paulo Zanoni <pzanoni@mandriva.com> Reviewed-by: Matt Dew Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit a72467b21662a63c81418731b540a8843d138750 Author: Paulo Zanoni <pzanoni@mandriva.com> Date: Thu Dec 16 13:59:52 2010 -0200 Use docbookx.dtd version 4.3 for all docs Signed-off-by: Paulo Zanoni <pzanoni@mandriva.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit e0280caf7cc9d0e1c2df3ab7c5a4fbe4e42696a9 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Dec 5 01:15:42 2010 -0800 Convert src/process.c from malloc + sprintf to asprintf Includes simple local implemenation of asprintf if configure doesn't find one in system libraries Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Julien Cristau <jcristau@debian.org> commit a5669dcb488db19b1ba4f1ef4d4565b6c3d1ea09 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Nov 20 19:47:53 2010 -0800 config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS Regroup AC statements under the Autoconf initialization section. Regroup AM statements under the Automake initialization section. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit d902a9f27369fc8388774e73f4bee6ab0ad86ef5 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sat Nov 20 19:45:42 2010 -0800 config: Remove unnecessary calls from configure.ac AC_PROG_CC is provided by XORG_DEFAULT_OPTIONS now PKG_CONFIG_MODULES handles AC_SUBST of the CFLAGS & LIBS variables Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit fd56c4e00a564d6385ccb2f8fadf10de201ae411 Author: Gaetan Nadon <memsize@videotron.ca> Date: Tue Nov 9 11:28:48 2010 -0500 config: HTML file generation: use the installed copy of xorg.css Currenlty the xorg.css file is copied in each location where a DocBook/XML file resides. This produces about 70 copies in the $(docdir) install tree. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 9856f5679b2b2d458cf830c1e8fdd206c724dfc5 Author: Adam Jackson <ajax@redhat.com> Date: Tue Oct 19 11:19:08 2010 -0400 libICE 1.0.7 Signed-off-by: Adam Jackson <ajax@redhat.com> commit 59a8d5609398824c81b72deb82735a55332ca239 Author: Jeremy Huddleston <jeremyhu@apple.com> Date: Sun Oct 17 21:26:31 2010 -0700 Fix include ordering, so -I../include precedes $CPPFLAGS which could cause us to include installed rather than packaged headers. Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com> commit 4a6f7a357222b2c1fa289d6e7b5fcc8c361e20e9 Author: Jesse Adkins <jesserayadkins@gmail.com> Date: Tue Sep 28 13:30:01 2010 -0700 Purge cvs tags. Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 5bb806a65bf23a507b135abe1e4a8b3cabc7b8aa Author: Matt Dew <matt@osource.org> Date: Wed Jun 30 16:52:22 2010 -0400 specs: convert ICE doc/specs from xorg-docs module to DocBook XML Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 9b54f509832c50c1fac0edc0cb78e1a3454a56dc Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Tue Jun 8 20:12:53 2010 -0700 Move ICE protocol & API specs from xorg-docs module For now, just checked in and included in dist tarballs, not processed into a usable format - same as it was in xorg-docs Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> commit 1967c04c021a4cfd7b3cdd4efdc13610b4385a65 Author: Julien Cristau <jcristau@debian.org> Date: Tue May 11 16:36:20 2010 +0200 Set the close-on-exec flag for listening sockets This prevents xsm from leaking file descriptors to the processes it starts. X.Org bug#22932 <http://bugs.freedesktop.org/show_bug.cgi?id=22932> Reported-by: Kalle Olavi Niemitalo <kon@iki.fi> Signed-off-by: Julien Cristau <jcristau@debian.org> commit b6478dbedcca4d4cf44bd588c050bcc70c2f4963 Author: Gaetan Nadon <memsize@videotron.ca> Date: Mon Apr 5 19:50:40 2010 -0400 config: update AC_PREREQ statement to 2.60 Unrelated to the previous patches, the new value simply reflects the reality that the minimum level for autoconf to configure all x.org modules is 2.60 dated June 2006. ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 8e175ff18649bd30e862b6a6a5f82a4ed4d5241a Author: Gaetan Nadon <memsize@videotron.ca> Date: Mon Mar 29 14:53:48 2010 -0400 config: remove the pkgconfig pc.in file from EXTRA_DIST Automake always includes it in the tarball. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 09d61dc024d9846525e4c97d33cdf03c9f06c151 Author: Gaetan Nadon <memsize@videotron.ca> Date: Tue Feb 16 10:37:21 2010 -0500 config: move CWARNFLAGS from configure.ac to Makefile.am Compiler warning flags should be explicitly set in the makefile rather than being merged with other packages compiler flags. Signed-off-by: Gaetan Nadon <memsize@videotron.ca> commit 72b8a2d39a57eb0640929b9bb9f276c6032f8213 Author: Gaetan Nadon <memsize@videotron.ca> Date: Fri Nov 27 20:56:03 2009 -0500 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Now that the INSTALL file is generated. Allows running make maintainer-clean. commit 68231f8574e197a12eff1ddde37166d101567269 Author: Gaetan Nadon <memsize@videotron.ca> Date: Wed Oct 28 14:09:10 2009 -0400 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Add missing INSTALL file. Use standard GNU file on building tarball README may have been updated Remove AUTHORS file as it is empty and no content available yet. Remove NEWS file as it is empty and no content available yet. commit b5cfc1cdd367c93660259a86b3b6683c57e5d76a Author: Gaetan Nadon <memsize@videotron.ca> Date: Tue Oct 27 15:07:25 2009 -0400 Deploy the new XORG_DEFAULT_OPTIONS #24242 This macro aggregate a number of existing macros that sets commmon X.Org components configuration options. It shields the configuration file from future changes. commit 5524fa4d543932e4565b2235515fef9a5d9a501d Author: Gaetan Nadon <memsize@videotron.ca> Date: Mon Oct 26 22:08:41 2009 -0400 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 ChangeLog filename is known to Automake and requires no further coding in the makefile. commit 82ad2d2053af2ad37697793b9718721aa3ff80a0 Author: Gaetan Nadon <memsize@videotron.ca> Date: Thu Oct 22 12:34:18 2009 -0400 .gitignore: use common defaults with custom section # 24239 Using common defaults will reduce errors and maintenance. Only the very small or inexistent custom section need periodic maintenance when the structure of the component changes. Do not edit defaults. commit 4b2289ad5481de7fa51941cf6c2ca7a2a3202690 Author: Jeremy Huddleston <jeremyhu@freedesktop.org> Date: Wed Oct 21 12:47:23 2009 -0700 This is not a GNU project, so declare it foreign. On Wed, 2009-10-21 at 13:36 +1000, Peter Hutterer wrote: > On Tue, Oct 20, 2009 at 08:23:55PM -0700, Jeremy Huddleston wrote: > > I noticed an INSTALL file in xlsclients and libXvMC today, and it > > was quite annoying to work around since 'autoreconf -fvi' replaces > > it and git wants to commit it. Should these files even be in git? > > Can I nuke them for the betterment of humanity and since they get > > created by autoreconf anyways? > > See https://bugs.freedesktop.org/show_bug.cgi?id=24206 As an interim measure, replace AM_INIT_AUTOMAKE([dist-bzip2]) with AM_INIT_AUTOMAKE([foreign dist-bzip2]). This will prevent the generation of the INSTALL file. It is also part of the 24206 solution. Signed-off-by: Jeremy Huddleston <jeremyhu@freedesktop.org> commit 94992c686a6850f2303aa78057a64a6369b64692 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Aug 28 14:17:50 2009 +1000 libICE 1.0.6 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> commit 7a8bb2a2c991919bcdef63359c74e239045a3f4c Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Mon Feb 2 20:34:30 2009 -0800 Add README with pointers to mailing list, bugzilla & git repos Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com> commit dbb950061f185e1ccf27bff9c71adc34ab4cfae0 Author: Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br> Date: Wed Jan 28 16:55:37 2009 -0200 Janitor: Correct sparse warnings. Also reorders some code in configure.ac and Makefile.am to match pattern used on other packages. commit 2f41ddb3a917c4e71184452b68561a15593d33b8 Author: Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br> Date: Tue Jan 6 17:25:25 2009 -0200 Update .gitignore. Don't warn about files left after a build and/or make distcheck in 'git status -a'. commit ab9dff549534c6d7b33f440bff7a841d60c1206c Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Mon Dec 8 18:45:44 2008 +0100 bump to 1.0.5 commit 71695c4bf7ae07228605683f6cdeca0457c8495a Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Mon Dec 8 18:44:26 2008 +0100 remove ChangeLog from EXTRA_DIST and CLEANFILES commit 653f659fe65ae8c2a9fe5b1fdbfc78da43f2cf90 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Mon Dec 8 18:41:34 2008 +0100 use memcmp instead of binaryEqual suggested by Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br> http://lists.freedesktop.org/archives/xorg/2008-December/041222.html commit bf138553afe6eecd0e6c218dc6ae4f63065e4196 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Tue Dec 2 22:06:15 2008 +0100 Use NULL, not zero, for pointers From Magnus Kessler <Magnus.Kessler@gmx.net> http://lists.freedesktop.org/archives/xorg/2008-October/039799.html http://lists.freedesktop.org/archives/xorg/attachments/20081030/b2ea5b1c/attachment-0001.bin commit b01e82ce1deedb36c9696d4d27a3b9a5d5a52d08 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Thu Oct 30 12:01:06 2008 +0100 ANSI C convert all old style function declarations see also: Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br> http://bugs.freedesktop.org/show_bug.cgi?id=14683 http://bugs.freedesktop.org/attachment.cgi?id=14582 see also: Magnus Kessler <Magnus.Kessler@gmx.net> http://lists.freedesktop.org/archives/xorg/2008-October/039799.html http://lists.freedesktop.org/archives/xorg/attachments/20081030/b2ea5b1c/attachment-0001.bin commit 2aba1bc0583aeb3ee6e26e3bfacd123abef744d9 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Mon Dec 1 23:06:22 2008 +0100 towards ANSI C make _IceProcessCoreMessage and default error handlers static commit 69a1b4b6d34291738dfbc3aa19d0ce3f2842ec8f Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Mon Dec 1 22:22:12 2008 +0100 Activate CWARNFLAGS with lots of gcc warnings commit 898ed95cad1133940a83dcf428865c5d3fb2c939 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Mon Dec 1 22:18:45 2008 +0100 use xorg-macros-1.2.1 Use XORG_CHANGELOG for rule to generate ChangeLog from git log Use XORG_CWARNFLAGS for compiler warning flags, leave CFLAGS to user commit a99fbad09ab850e65ddd57e4d4488e4726295e14 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Tue Oct 7 13:21:48 2008 -0700 Constify some arguments in libICE to clear warnings in libSM This patch avoids the gcc (3.4.6) warnings: ../../libSM-1.0.3/src/sm_client.c:104: warning: passing arg 7 of `IceRegisterForProtocolSetup' from incompatible pointer type ../../libSM-1.0.3/src/sm_manager.c:168: warning: passing arg 7 of `IceRegisterForProtocolReply' from incompatible pointer type when compiling libSM commit 3bceaeb3192ca75a14854d614e1621d28fb82274 Author: Peter Breitenlohner <peb@mppmu.mpg.de> Date: Tue Oct 7 11:25:42 2008 -0700 define macros to 1 in icetrans.c to avoid redefined macro warnings X.Org Bug #17947 <http://bugs.freedesktop.org/show_bug.cgi?id=17947> Patch #19444 <http://bugs.freedesktop.org/attachment.cgi?id=19444> Define as 1 (one) as done by autoconf and the command line option, e.g. -DICE_t, not as empty. This avoids the gcc (3.4.6) warnings: ../../libICE-1.0.4/src/icetrans.c:29:1: warning: "ICE_t" redefined ../config.h:38:1: warning: this is the location of the previous definition ../../libICE-1.0.4/src/icetrans.c:30:1: warning: "TRANS_CLIENT" redefined <command line>:6:1: warning: this is the location of the previous definition ../../libICE-1.0.4/src/icetrans.c:31:1: warning: "TRANS_SERVER" redefined <command line>:7:1: warning: this is the location of the previous definition commit b707104f4dba0963ab17c1d6a29c1e3a848ea408 Author: Alan Hourihane <alanh@tungstengraphics.com> Date: Tue Apr 29 00:41:40 2008 +0100 silence warning commit e6b525aefc05b5203391699b00053ad52243cc6b Author: Colin Harrison <colin.harrison-at-virgin.net> Date: Tue Apr 29 00:40:48 2008 +0100 include for sleep() commit ef58f37724b841ef2246757be27111775aa86559 Author: Matthieu Herrb <matthieu.herrb@laas.fr> Date: Sun Mar 9 09:02:40 2008 +0100 nuke RCS Ids commit 47d86e8343d3d0201166c4d75da2ec9c12638cc1 Author: James Cloos <cloos@jhcloos.com> Date: Thu Dec 6 15:51:13 2007 -0500 Add missing PHONY line for automatic ChangeLog generation commit f415da71dd26f128df7d550ecd7631f8888eb1d2 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Mon Aug 20 13:21:07 2007 -0700 Version bump: 1.0.4 commit 8e08d3e4b8f00151b3a8b7eb88015dc15170e154 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Mon Jun 4 15:40:22 2007 -0700 Add $(AM_CFLAGS) to lint flags to get correct Xtrans flags commit cd900e40b5676874d076c35466fd7baa6a49b1f6 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 15:05:52 2007 -0700 Replace many malloc(strlen()); strcpy() pairs with strdup() commit 27f9a9324d58c9a7472c724c62f5b7ea0e1f4681 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 14:43:05 2007 -0700 Provide ANSI C prototypes for more static functions commit bb639803a779ceace05d183b653da88f010ab29c Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 14:32:31 2007 -0700 Convert authutil.c static helpers to ANSI C prototypes to clear sparse warnings commit 2179b2d467d69e45559b8e4f161a904a21f05321 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 14:28:06 2007 -0700 Add hooks for checking source code with lint/sparse/etc. commit 6b361c028b5ad931b61df86fae570f3ef9f41c15 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 14:19:56 2007 -0700 Coverity #1086: Double free of pointer "*listenObjsRet" Same bug, different function. commit c9b3d016681d81aff32c74cdad75151bd538e6ab Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 14:07:42 2007 -0700 Coverity #1085: Double free of pointer "*listenObjsRet" If malloc failed in the loop in IceListenForConnections, the error path would free all previous allocations, then loop around and try again, and if it failed again, free the previous allocations again. On the other hand, if it succeeded on the later tries, then the memory would just be leaked, since the error would be returned and not the pointer to them. commit 6039e865470af23948b0fe7d5dc0ea72da436b0e Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Apr 5 14:04:01 2007 -0700 Add *~ to .gitignore to skip emacs/patch droppings commit bed718894bed98cbd45b02bd57fb7fc6fd5089aa Author: Daniel Stone <daniel@fooishbar.org> Date: Sat Dec 16 01:21:17 2006 +0200 bump to 1.0.3 commit cac788981906186442ddfb57a41f45911eb8223b Author: Daniel Stone <daniel@fooishbar.org> Date: Wed Dec 6 18:58:09 2006 +0200 Makefile.am: make ChangeLog hook safer Make ChangeLog hook as safe as possible. commit 011d632e8ef3f738b9158e66d6da6876e3b53905 Author: Adam Jackson <ajax@benzedrine.nwnk.net> Date: Fri Oct 13 15:49:52 2006 -0400 Bump to 1.0.2 commit 445661cd714685009ee9ba2358a274351381eabf Author: Adam Jackson <ajax@benzedrine.nwnk.net> Date: Thu Oct 12 18:37:57 2006 -0400 Fix ChangeLog hook to distcheck. commit 5cba1c763ac9f79062523227b49a29f72e6069cf Author: Matthieu Herrb <matthieu.herrb@laas.fr> Date: Sun Jul 16 10:52:30 2006 +0200 set GIT_DIR=${srcdir}/.git for git-log commit 86e0a93714a6ccdb8555fc2c48231d958cba383d Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Thu Jul 13 14:58:44 2006 -0700 renamed: .cvsignore -> .gitignore commit c87cb98979356fc55607c05a2b23207afc9beeb1 Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Tue Jul 11 13:48:08 2006 -0700 Replace static ChangeLog with rule copied from libX11 to generate from git log commit 6066ab9b9914ec0cca3b8f36fa3f5ba323414621 Author: Derek Wang <derek.wang@sun.com> Date: Tue Nov 23 12:00:32 2004 -0800 Sun bug #6193975: kde session manager core dumps in _IceWrite() commit be25425ca38d23655a5a854c053e750e1cbd3dea Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Tue Jul 11 13:42:07 2006 -0700 renamed: .cvsignore -> .gitignore commit 9b1bb5ab99bd386cc030cd456a576b37406da91c Author: Adam Jackson <ajax@nwnk.net> Date: Wed Apr 26 23:57:50 2006 +0000 Bump to 1.0.1 commit 96d7763487da6624ed85bee10b081e7138d2060d Author: Alan Coopersmith <Alan.Coopersmith@sun.com> Date: Mon Apr 10 16:44:40 2006 +0000 Coverity #664: Free memory allocated by EXTRACT_STRING in _IceDefaultErrorHandler after we're done fprintf()'ing it. commit 2a30ec82f3bd2aa1f2566e97fee70403a8448de8 Author: Kevin E Martin <kem@kem.org> Date: Thu Dec 15 00:24:27 2005 +0000 Update package version number for final X11R7 release candidate. commit 881573d429c0a9ecfa2d6286d4eaece36ee50675 Author: Kevin E Martin <kem@kem.org> Date: Sat Dec 3 05:49:42 2005 +0000 Update package version number for X11R7 RC3 release. commit a15b179f2e8e359161d9133bac58dde57b7e78ae Author: Kevin E Martin <kem@kem.org> Date: Sat Nov 19 07:15:39 2005 +0000 Update pkgconfig files to separate library build-time dependencies from application build-time dependencies, and update package deps to work with separate build roots. commit c386a08047582240adefafd3afc062e52fccae6f Author: Kevin E Martin <kem@kem.org> Date: Wed Nov 9 21:19:12 2005 +0000 Update package version number for X11R7 RC2 release. commit c361e3919f2de3f4742904b04e73178edc76bf95 Author: Adam Jackson <ajax@nwnk.net> Date: Sun Oct 23 20:12:19 2005 +0000 Bug #1893: Fix replies when peers use different major opcodes for the same subprotocol. (016_ICE_subprotocol_reply_fix.diff from Debian, by Jochen Voss) commit 0b8ff6fbd8cd7f47ab9e6ccb6d4917564a2d13ee Author: Alan Coopersmith <Alan.Coopersmith@sun.com> Date: Sat Jul 30 19:15:15 2005 +0000 Add -D flags to clear various warnings (Stefan Dirsch) commit 260d470a128c7eaa6d7484bb143aab353c4e98ec Author: Kevin E Martin <kem@kem.org> Date: Fri Jul 29 21:22:50 2005 +0000 Various changes preparing packages for RC0: - Verify and update package version numbers as needed - Implement versioning scheme - Change bug address to point to bugzilla bug entry form - Disable loadable i18n in libX11 by default (use --enable-loadable-i18n to reenable it) - Fix makedepend to use pkgconfig and pass distcheck - Update build script to build macros first - Update modular Xorg version commit cf687b775f580a84a4a8e962814abe7bc47a3c52 Author: Daniel Stone <daniel@fooishbar.org> Date: Sat Jul 16 06:22:34 2005 +0000 Set soversion to 6.3.0. commit 6d1704defa0e57715bd22d30d6e789b36233dcf8 Author: Keith Packard <keithp@keithp.com> Date: Sat Jul 9 05:59:01 2005 +0000 Add .cvsignore files commit 2b6b8e40a63dd69a13f87c19dcf8dc2f477c304d Author: Daniel Stone <daniel@fooishbar.org> Date: Sun Jul 3 07:00:55 2005 +0000 Add Xtrans definitions (FONT_t, TRANS_CLIENT) to clean up warnings. Add XSERV_t, TRANS_SERVER, TRANS_REOPEN to quash warnings. Add #include <dix-config.h> or <xorg-config.h>, as appropriate, to all source files in the xserver/xorg tree, predicated on defines of HAVE_{DIX,XORG}_CONFIG_H. Change all Xfont includes to <X11/fonts/foo.h>. commit 608ad35f102b188f554daf8c160a5edcf4e8031c Author: Daniel Stone <daniel@fooishbar.org> Date: Fri Jun 10 14:11:36 2005 +0000 Remove pointless include of Xlib.h. Fix #include path to bigreqstr.h. commit 795460992b0dcd4aa2591be462a94942415c6028 Author: Alexander Gottwald <alexander.gottwald@s1999.tu-chemnitz.de> Date: Thu Jun 9 15:54:47 2005 +0000 Replace <X11/transport.c> with <X11/Xtrans/transport.c> commit ae7b4cca6bd5c1f4edea8cde80d7a3dfaaf2c4d3 Author: Alexander Gottwald <alexander.gottwald@s1999.tu-chemnitz.de> Date: Thu Jun 9 15:52:02 2005 +0000 Replace <X11/Xtrans.h> with <X11/Xtrans/Xtrans.h> Copy Xtrans.h to exports/include/X11/Xtrans only commit a0637be926e6da5db8d131e7914f1300f484c626 Author: Alan Coopersmith <Alan.Coopersmith@sun.com> Date: Sat May 21 23:07:47 2005 +0000 xtrans: Create autoconf macro XTRANS_CONNECTION_FLAGS to provide standard set of --enable flags for which transports to support and common place to update for required libraries for platforms that need certain libs for certain transports ICE: Add ICE_t #define required by Xtrans headers. Replace static defines of LOCALCONN & UNIXCONN with new XTRANS_CONNECTION_FLAGS macro. X11: Moved transport type checks to new macro XTRANS_CONNECTION_FLAGS in xtrans.m4 in xtrans module so they can be shared by all modules using xtrans. commit efdb2468119be0c62a379d91088a708ca8d37e1b Author: Adam Jackson <ajax@nwnk.net> Date: Thu May 19 00:22:32 2005 +0000 revert last change, didn't do right thing at all, sorry for the noise commit ccf4efa5e204d4569b9b590f72baae807ec19903 Author: Adam Jackson <ajax@nwnk.net> Date: Thu May 19 00:10:02 2005 +0000 Require automake 1.7 in AM_INIT_AUTOMAKE commit 3458da101c943530861485c798538ce014eee6b0 Author: Søren Sandmann Pedersen <sandmann@daimi.au.dk> Date: Tue May 17 21:25:15 2005 +0000 - Conditionally include config.h in xc/lib/SM - Add libSM to symlink.sh - Add SM build system commit cae06ca0ce523eeb9a667ce3ae5bff066cf6ecd7 Author: Søren Sandmann Pedersen <sandmann@daimi.au.dk> Date: Tue May 17 20:53:58 2005 +0000 - Conditionally include config.h in the ICE source. - Add ICE to symlink.sh commit 9dd90f8f8e29bb1dd6fe84b4b1d2d75ef91bc336 Author: Søren Sandmann Pedersen <sandmann@daimi.au.dk> Date: Tue May 17 20:52:35 2005 +0000 Add ICE directory + build system. commit d1cfe2a6d4a392f64b6b9d9255ec329fb2a6a39a Author: Daniel Stone <daniel@fooishbar.org> Date: Fri Jan 28 19:15:39 2005 +0000 Move _IceGetPeerName into the ICE public API as IceGetPeerName; bump ICE soversion to 6.4 accordingly. Change SM's use to the public version. The old version will be retained for compatibility. commit 8f0babf8450aa8097e063e13c95b1581843b2dd8 Author: Egbert Eich <eich@suse.de> Date: Fri Apr 23 18:43:22 2004 +0000 Merging XORG-CURRENT into trunk commit 111949a4a1d5b62e26016b555e12f8862c90ae44 Author: Egbert Eich <eich@suse.de> Date: Sun Mar 14 08:31:52 2004 +0000 Importing vendor version xf86-4_4_99_1 on Sun Mar 14 00:26:39 PST 2004 commit d4054eea34b2f4d345796ecadec8a96af93c4d0d Author: Egbert Eich <eich@suse.de> Date: Wed Mar 3 12:11:10 2004 +0000 Importing vendor version xf86-4_4_0 on Wed Mar 3 04:09:24 PST 2004 commit 569bf16d182b043e7ab914202d4195baf4a8413a Author: Egbert Eich <eich@suse.de> Date: Thu Feb 26 13:35:18 2004 +0000 readding XFree86's cvs IDs commit 14c9e41e551ab1b3a00807dbb8f2f215b96bcc81 Author: Egbert Eich <eich@suse.de> Date: Thu Feb 26 09:22:34 2004 +0000 Importing vendor version xf86-4_3_99_903 on Wed Feb 26 01:21:00 PST 2004 commit 45b73c360dc68b023194758bbb1cc59c021742a6 Author: Kaleb Keithley <kaleb@freedesktop.org> Date: Thu Dec 4 22:02:52 2003 +0000 XFree86 4.3.99.901 (RC 1) commit c919c3d0b355ef67dfa0b511eb1da488e5786d1b Author: Kaleb Keithley <kaleb@freedesktop.org> Date: Tue Nov 25 19:28:07 2003 +0000 XFree86 4.3.99.16 Bring the tree up to date for the Cygwin folks commit 72e353567f8927996a26e72848d86f692c3f0737 Author: Kaleb Keithley <kaleb@freedesktop.org> Date: Fri Nov 14 16:48:46 2003 +0000 XFree86 4.3.0.1 commit ee452992357329f7af846eba8f5bbe61c5d27bfa Author: Kaleb Keithley <kaleb@freedesktop.org> Date: Fri Nov 14 15:54:36 2003 +0000 R6.6 is the Xorg base-line PK t��[$'V� E E ice.xmlnu �[��� PK t��[ƚ�� � UE AUTHORSnu �[��� PK t��[�C�e� � JF COPYINGnu �[��� PK t��[,�p|C |C K ICElib.xmlnu �[��� PK t��[���� � Ȏ ChangeLognu �[��� PK h ��
| ver. 1.6 |
Github
|
.
| PHP 8.2.30 | ??????????? ?????????: 0 |
proxy
|
phpinfo
|
???????????