1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
3 "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
8 <title>X Display Manager Control Protocol</title>
9 <subtitle>X.Org Standard</subtitle>
10 <releaseinfo>Version 1.1</releaseinfo>
13 <firstname>Keith</firstname><surname>Packard</surname>
14 <affiliation><orgname>
16 Laboratory for Computer Science,
17 Massachusetts Institute of Technology
18 </orgname></affiliation>
22 <copyright><year>1989</year><holder>The Open Group</holder></copyright>
23 <copyright><year>2004</year><holder>The Open Group</holder></copyright>
24 <productnumber>X Version 11, Release 6.8</productnumber>
31 Permission is hereby granted, free of charge, to any person obtaining a copy
32 of this software and associated documentation files (the "Software"), to deal
33 in the Software without restriction, including without limitation the rights
34 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
35 copies of the Software, and to permit persons to whom the Software is
36 furnished to do so, subject to the following conditions:
39 The above copyright notice and this permission notice shall be included in
40 all copies or substantial portions of the Software.
43 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
44 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
45 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
46 OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
47 AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
48 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
51 Except as contained in this notice, the name of The Open Group shall not be
52 used in advertising or otherwise to promote the sale, use or other dealings
53 in this Software without prior written authorization from The Open Group.
57 <emphasis remap='I'>X Window System</emphasis> is a trademark of The Open Group.
64 <sect1 id="Purpose_and_Goals">
65 <title>Purpose and Goals</title>
67 <!-- (SN Purpose and Goals -->
71 The purpose of the X Display Manager Control Protocol (XDMCP)
72 is to provide a uniform mechanism for an autonomous
73 display to request login service from a remote host.
74 By autonomous, we mean
75 the display consists of hardware and processes that are independent of any
76 particular host where login service is desired. (For example, the server
77 cannot simply be started by a
78 <function>fork/exec</function>
79 sequence on the host.)
80 An X terminal (screen, keyboard, mouse, processor, network interface)
81 is a prime example of an autonomous display.
85 From the point of view of the end user, it is very important to make
86 autonomous displays as easy to use as traditional hardwired character
87 terminals. Specifically, you can typically just power on a hardwired
88 terminal and be greeted with a login prompt. The same should be possible
89 with autonomous displays. However, in a network environment with multiple
90 hosts, the end user may want to choose which host(s) to connect to. In an
91 environment with many displays and many hosts, a site administrator may want
92 to associate particular collections of hosts with particular displays. We
93 would like to support the following options:
99 The display has a single, fixed host to which it should connect. It should be
100 possible to power on the display and receive a login prompt, without user
106 Any one of several hosts on a network or subnetwork may be acceptable
107 for accepting login from the display.
108 (For example, the user's file systems can be mounted onto
109 any such host, providing comparable environments.) It should be possible
110 for the display to broadcast to find such hosts and to have the display
111 either automatically choose a host or present the possible hosts to the
117 The display has a fixed set of hosts that it can connect to. It should be
118 possible for the display to have that set stored in RAM, but it should also be
119 possible for a site administrator to be able to maintain host sets for a
120 large number of displays using a centralized facility, without having to
121 interact (physically or electronically) with each individual display.
122 Particular hosts should be allowed to refuse login service, based on
123 whatever local criteria are desired.
129 The control protocol should be designed in such a way that it can be used over
130 a reasonable variety of communication transport layers. In fact, it is quite
131 desirable if every major network protocol family that supports the standard X
132 protocol is also capable of supporting XDMCP, because the end result of XDMCP
133 negotiation will be standard X protocol connections to the display.
134 However, because the number of displays per host may be large,
135 a connection-based protocol appears less desirable
136 than a connection-less protocol. For this reason the protocol is designed
137 to use datagram services with the display responsible for sequencing and
142 To keep the burden on displays at a minimum (because display cost is not
143 a factor that can be ignored), it is desirable that displays not be required
144 to maintain permanent state (across power cycles) for the purposes
145 of the control protocol,
146 and it is desirable to keep required state at a minimum while the
147 display is powered on.
151 Security is an important consideration and must be an integral part of the
152 design. The important security goals in the context of XDMCP are:
157 It should be possible for the display to verify that it is communicating
158 with a legitimate host login service. Because the user will present
159 credentials (for example, password) to this service,
160 it is important to avoid spoof attacks.
165 It should be possible for the display and the login service to negotiate the
166 authorization mechanism to be used for the standard X protocol.
171 It should be possible to provide the same level of security in verifying the
172 login service as is provided by the negotiated authorization mechanism.
177 Because there are no firm standards yet in the area of security,
178 XDMCP must be flexible enough to accomodate a variety of security mechanisms.
184 <sect1 id="Overview_of_the_Protocol">
185 <title>Overview of the Protocol</title>
187 <!-- (SN Overview of the Protocol -->
191 XDMCP is designed to provide authenticated access to display management
192 services for remote displays. A new network server, called a \fIDisplay
193 Manager\fP, will use XDMCP to communicate with displays to negotiate the
194 startup of X sessions. The protocol allows the display to authenticate the
195 manager. It also allows most of the configuration information to be
196 centralized with the manager and to ease the burden of system administration
197 in a large network of displays.
198 The essential goal is to provide plug-and-play
199 services similar to those provided in the familiar mainframe/terminal world.
203 Displays may be turned off by the user at any time. Any existing session
204 running on a display that has been turned off must be identifiable. This
205 is made possible by requiring a three-way handshake to start a session. If
206 the handshake succeeds, any existing session is terminated immediately and a
207 new session started. There is the problem (at least with TCP) that
208 connections may not be closed when the display is turned off. In most
209 environments, the manager should reduce this problem by periodically XSync'ing
210 on its own connection, perhaps every five to ten minutes, and terminating the
211 session if its own connection ever closes.
215 Displays should not be required to retain permanent state for purposes of
216 the control protocol. One solution to packets received out of sequence
217 would be to use monotonically increasing message identifiers in each message
218 to allow both sides to ignore messages that arrive out-of-sequence. For
219 this to work, displays would at a minimum have to increment a stable crash
220 count each time they are powered on and use that number as part of a
221 larger sequence number. But if displays cannot retain permanent state this
222 cannot work. Instead, the manager assumes the responsibility for permanent
223 state by generating unique numbers that identify a particular session and
224 the protocol simply ignores packets that correspond to an invalid session.
228 The Manager must not be responsible for packet reception. To prevent the
229 Manager from becoming stuck because of a hostile display, no portion of the
230 protocol requires the Manager to retransmit a packet. Part of this means
231 that any valid packet that the Manager does receive must be
232 acknowledged in some way to prevent the display from continuously resending
233 packets. The display can keep the protocol running as it will always know
234 when the Manager has received (at least one copy of) a packet. On the
235 Manager side, this means that any packet may be received more than once (if
236 the response was lost) and duplicates must be ignored.
240 <sect1 id="Data_Types">
241 <title>Data Types</title>
243 <!-- (SN Data Types -->
247 XDMCP packets contain several types of data. Integer values are always
248 stored most significant byte first in the packet ("Big Endian" order).
249 As XDMCP will not be used to transport large quantities of data, this
250 restriction will not substantially hamper the efficiency of any
251 implementation. Also, no padding of any sort will occur within the packets.
254 <informaltable frame="none">
255 <tgroup cols='3' align='left'>
256 <colspec colname='c1' colsep="0"/>
257 <colspec colname='c2' colsep="0"/>
258 <colspec colname='c3' colsep="0"/>
261 <entry>Type Name</entry>
262 <entry>Length (Bytes)</entry>
263 <entry>Description</entry>
270 <entry>A single byte unsigned integer</entry>
273 <entry>CARD16</entry>
275 <entry>Two byte unsigned integer</entry>
278 <entry>CARD32</entry>
280 <entry>Four byte unsigned integer</entry>
283 <entry>ARRAY8</entry>
286 This is actually a CARD16 followed by
287 a collection of CARD8. The value of the CARD16
288 field (n) specifies the number of CARD8 values to follow
292 <entry>ARRAY16</entry>
295 This is a CARD8 (m) which specifies the
296 number of CARD16 values to follow
300 <entry>ARRAY32</entry>
303 This is a CARD8 (l) which specifies the
304 number of CARD32 values to follow
308 <entry>ARRAYofARRAY8</entry>
311 This is a CARD8 which specifies the
312 number of ARRAY8 values to follow.
320 <sect1 id="Packet_Format">
321 <title>Packet Format</title>
323 <!-- (SN Packet Format -->
326 All XDMCP packets have the following information:
329 <informaltable frame="none">
330 <tgroup cols='3' align='left'>
331 <colspec colname='c1' colsep="0"/>
332 <colspec colname='c2' colsep="0"/>
333 <colspec colname='c3' colsep="0"/>
336 <entry>Length (Bytes)</entry>
337 <entry>Field Type</entry>
338 <entry>Description</entry>
344 <entry>CARD16</entry>
345 <entry>version number</entry>
349 <entry>CARD16</entry>
350 <entry>opcode packet header</entry>
354 <entry>CARD16</entry>
355 <entry>n = length of remaining data in bytes</entry>
360 <entry>packet-specific data</entry>
368 The fields are as follows:
373 <term>Version number</term>
376 This specifies the version of XDMCP that generated this packet in
377 case changes in this protocol are required. Displays and
378 managers may choose to support older versions for compatibility.
379 This field will initially be one (1).
387 This specifies what step of the protocol this packet represents and should
388 contain one of the following values (encoding provided in section below):
389 <emphasis role="bold">BroadcastQuery</emphasis>,
390 <emphasis role="bold">Query</emphasis>,
391 <emphasis role="bold">IndirectQuery</emphasis>,
392 <emphasis role="bold">ForwardQuery</emphasis>,
393 <emphasis role="bold">Willing</emphasis>,
394 <emphasis role="bold">Unwilling</emphasis>,
395 <emphasis role="bold">Request</emphasis>,
396 <emphasis role="bold">Accept</emphasis>,
397 <emphasis role="bold">Decline</emphasis>,
398 <emphasis role="bold">Manage</emphasis>,
399 <emphasis role="bold">Refuse</emphasis>,
400 <emphasis role="bold">Failed</emphasis>,
401 <emphasis role="bold">KeepAlive</emphasis>
403 <emphasis role="bold">Alive</emphasis>.
408 <term>Length of data in bytes</term>
411 This specifies the length of the information following the first 6 bytes.
412 Each packet-type has a different format and will need to be separately
413 length-checked against this value. Because every data item has either an
414 explicit or implicit length, this can be easily accomplished.
415 Packets that have too little or too much data should be ignored.
421 Packets should be checked to make sure that they satisfy the following
428 They must contain valid opcodes.
433 The length of the remaining data should correspond to the sum of the
434 lengths of the individual remaining data items.
439 The opcode should be expected (a finite state diagram is given
445 If the packet is of type
446 <emphasis role="bold">Manage</emphasis> or
447 <emphasis role="bold">Refuse</emphasis>,
448 the Session ID should match the value sent in the preceding
449 <emphasis role="bold">Accept</emphasis> packet.
455 <sect1 id="Protocol">
456 <title>Protocol</title>
458 <!-- (SN Protocol -->
461 Each of the opcodes is described below. Because a given packet type is only
462 ever sent one way, each packet description below indicates the direction.
463 Most of the packets have additional information included beyond the
464 description above. The additional information is appended to the packet
465 header in the order described without padding, and the length field is
466 computed accordingly.
469 <informaltable frame="none">
470 <tgroup cols='10' align='left'>
471 <colspec colname='col1' colsep="0" colwidth="1*"/>
472 <colspec colname='col2' colsep="0" colwidth="1*"/>
473 <colspec colname='col3' colsep="0" colwidth="1*"/>
474 <colspec colname='col4' colsep="0" colwidth="1*"/>
475 <colspec colname='col5' colsep="0" colwidth="1*"/>
476 <colspec colname='col6' colsep="0" colwidth="1*"/>
477 <colspec colname='col7' colsep="0" colwidth="1*"/>
478 <colspec colname='col8' colsep="0" colwidth="1*"/>
479 <colspec colname='col9' colsep="0" colwidth="1*"/>
480 <colspec colname='col10' colsep="0" colwidth="1*"/>
481 <spanspec namest="col1" nameend="col10" spanname="col1_on" align="left"/>
482 <spanspec namest="col2" nameend="col10" spanname="col2_on" align="left"/>
483 <spanspec namest="col3" nameend="col10" spanname="col3_on" align="left"/>
484 <spanspec namest="col4" nameend="col10" spanname="col4_on" align="left"/>
485 <spanspec namest="col5" nameend="col10" spanname="col5_on" align="left"/>
488 <entry spanname="col1_on"><emphasis role="bold">Query</emphasis></entry>
491 <entry spanname="col1_on"><emphasis role="bold">BroadcastQuery</emphasis></entry>
494 <entry spanname="col1_on"><emphasis role="bold">IndirectQuery</emphasis></entry>
498 <entry spanname="col2_on">Display -> Manager</entry>
502 <entry spanname="col2_on">Additional Fields:</entry>
507 <entry spanname="col3_on">
508 <emphasis>Authentication Names</emphasis>: ARRAYofARRAY8
515 <entry spanname="col4_on">
516 Specifies a list of authentication names that the display supports. The
517 manager will choose one of these and return it in the
518 <emphasis role="bold">Willing</emphasis> packet.
521 <!-- AAAAAAAAAAAAA -->
525 <entry>Semantics</entry>
531 <entry spanname="col4_on">
533 A <function>Query</function>
534 packet is sent from the display to a specific host to ask if
535 that host is willing to provide management services to this display. The
536 host should respond with
537 <function>Willing</function>
538 if it is willing to service the display or
539 <function>Unwilling</function>
545 <function>BroadcastQuery</function>
546 packet is similar to the
547 <function>Query</function>
548 packet except that it is intended to be received by all hosts on the network
549 (or subnetwork). However, unlike
550 <function>Query</function>
551 requests, hosts that are not willing to service the display
553 <function>BroadcastQuery</function>
559 <function>IndirectQuery</function>
560 packet is sent to a well known manager that forwards
561 the request to a larger collection of secondary managers using
562 <function>ForwardQuery</function>
564 In this way, the collection of managers that respond can be grouped
565 on other than network boundaries; the use of a central manager reduces
566 system administrative overhead.
567 The primary manager may also send a
568 <function>Willing</function>
569 packet in response to this packet.
573 Each packet type has slightly different semantics:
582 <entry spanname="col5_on">
585 <function>Query</function>
586 packet is destined only for a single host.
587 If the display is instructed to
588 <function>Query</function>
589 multiple managers, it will send multiple
590 <function>Query</function>
592 <function>Query</function>
593 packet also demands a response from the manager, either
594 <function>Willing</function>
596 <function>Unwilling</function>.
600 <function>BroadcastQuery</function>
601 packet is sent to many hosts.
602 Each manager that receives this packet will not respond with an
603 <function>Unwilling</function>
608 <function>IndirectQuery</function>
609 packet is sent to only one manager with the request
610 that the request be forwarded to a larger list of managers using
611 <function>ForwardQuery</function>
612 packets. This list is expected to be maintained at one
613 central site to reduce administrative overhead.
614 The function of this packet type is similar to
615 <function>BroadcastQuery except that</function>
616 <function>BroadcastQuery</function>
625 <entry spanname="col4_on">Valid Responses:</entry>
630 <entry spanname="col3_on">
631 <function>Willing</function>,
632 <function>Unwilling</function>
639 <entry spanname="col4_on">Problems/Solutions:</entry>
644 <entry spanname="col3_on">Problem:</entry>
650 <entry spanname="col4_on">
651 <para>Not all managers receive the query packet.</para>
652 <para>Indication:</para>
660 <entry spanname="col5_on">
662 <function>BroadcastQuery</function>
664 <function>IndirectQuery</function>
665 was sent, else failure to receive
666 <function>Willing</function>.
673 <entry spanname="col4_on">Solution:</entry>
680 <entry spanname="col5_on">
681 Repeatedly send the packet while waiting for user to choose a manager.
687 <entry spanname="col3_on">
688 Timeout/Retransmission policy:
695 <entry spanname="col4_on">
696 An exponential backoff algorithm should be used here to reduce network load
697 for long-standing idle displays. Start at 2 seconds, back off by factors of
698 2 to 32 seconds, and discontinue retransmit after 126 seconds. The display
699 should reset the timeout when user-input is detected. In this way, the
700 display will wakeup when touched by the user.
704 <entry spanname="col1_on">
705 <function>ForwardQuery</function>
710 <entry spanname="col2_on">
711 <para>Primary Manager -> Secondary Manager</para>
712 <para>Additional Fields:</para>
718 <entry spanname="col3_on">
719 <emphasis remap='I'>Client Address</emphasis>: ARRAY8
726 <entry spanname="col4_on">
727 Specifies the network address of the client display.
733 <entry spanname="col3_on">
734 <emphasis remap='I'>Client Port</emphasis>: ARRAY8
741 <entry spanname="col4_on">
742 Specifies an identification of the client task on the client display.
748 <entry spanname="col3_on">
749 <emphasis remap='I'>Authentication Names</emphasis>: ARRAYofARRAY8
756 <entry spanname="col4_on">
757 Is a duplicate of Authentication Names array that was received
759 <function>IndirectQuery</function>
765 <entry spanname="col2_on">
772 <entry spanname="col3_on">
774 When primary manager receives a
775 <function>IndirectQuery</function>
776 packet, it is responsible for sending
777 <function>ForwardQuery</function>
778 packets to an appropriate list of
779 managers that can provide service to the display using the same network
780 type as the one the original
781 <function>IndirectQuery</function>
782 packet was received from.
783 The Client Address and Client Port fields must contain an
784 address that the secondary manager can use to reach the display also using
785 this same network. Each secondary manager sends a
786 <function>Willing</function>
787 packet to the display if it is willing to provide service.
791 <function>ForwardQuery</function>
792 packets are similar to
793 <function>BroadcastQuery</function>
794 packets in that managers that are not willing to service
795 particular displays should not send a
796 <function>Unwilling</function>
803 <entry spanname="col2_on">
811 <entry spanname="col3_on">
812 <function>Willing</function>
817 <entry spanname="col2_on">
824 <entry spanname="col3_on">
826 <function>BroadcastQuery</function>
831 <entry spanname="col2_on">
832 Timeout/Retransmission policy:
838 <entry spanname="col3_on">
839 Like all packets sent from a manager, this packet should never be
845 <entry spanname="col1_on">
846 <function>Willing</function>
852 <entry spanname="col2_on">
854 Manager -> Display
865 <entry spanname="col3_on">
866 <emphasis remap='I'>Authentication Name</emphasis>: ARRAY8
874 <entry spanname="col4_on">
876 Specifies the authentication method, selected from the list offered in the
877 <function>Query ,</function>
878 <function>BroadcastQuery ,</function>
880 <function>IndirectQuery</function>
881 packet that the manger expects the display to use in the subsequent
882 <function>Request</function>
884 This choice should remain as constant as feasible so that displays that
886 <function>Query</function>
887 packets can use the Authentication Name from any
888 <function>Willing</function>
892 The display is free to ignore managers that request an insufficient level
901 <entry spanname="col3_on">
902 <emphasis remap='I'>Hostname</emphasis>: ARRAY8
910 <entry spanname="col4_on">
911 Is a human readable string describing the host from which the packet was sent.
912 The protocol specifies no interpretation of the data in this field.
919 <entry spanname="col3_on">
920 <emphasis remap='I'>Status</emphasis>: ARRAY8
928 <entry spanname="col4_on">
929 Is a human readable string describing the status of the host. This could
930 include load average/number of users connected or other information. The
931 protocol specifies no interpretation of the data in this field.
938 <entry spanname="col2_on">
946 <entry spanname="col3_on">
948 <function>Willing</function>
949 packet is sent by managers that may service connections from
950 this display. It is sent in response to either a
951 <function>Query ,</function>
952 <function>BroadcastQuery ,</function>
954 <function>ForwardQuery</function>
955 but does not imply a commitment to provide service
956 (for example, it may later decide that it has accepted enough
957 connections already).
963 <entry spanname="col2_on">
971 <entry spanname="col3_on">
980 <entry spanname="col4_on">
982 <function>Willing</function>
983 not received by the display.
996 <entry spanname="col5_on">
998 <function>BroadcastQuery</function>
1000 <function>IndirectQuery</function>
1001 was sent, else failure to receive
1002 <function>Willing .</function>
1010 <entry spanname="col4_on">
1020 <entry spanname="col5_on">
1021 The display should continue to send the query until a response is received.
1029 <entry spanname="col2_on">
1030 Timeout/Retransmission policy:
1037 <entry spanname="col3_on">
1038 Like all packets sent from the manager to the display, this packet should
1039 never be retransmitted.
1044 <entry spanname="col1_on">
1045 <function>Unwilling</function>
1051 <entry spanname="col2_on">
1053 Manager -> Display
1064 <entry spanname="col3_on">
1065 The Hostname and Status fields as in the
1066 <function>Willing</function>
1068 The Status field should indicate to the user a reason
1069 for the refusal of service.
1075 <entry spanname="col2_on">
1083 <entry spanname="col3_on">
1085 <function>Unwilling</function>
1086 packet is sent by managers in response to direct
1087 <function>Query</function>
1088 requests (as opposed to
1089 <function>BroadcastQuery</function>
1091 <function>IndirectQuery</function>
1092 requests) if the manager will not accept requests for management.
1093 This is typically sent by managers that wish to only service
1094 particular displays or that handle a limited number of displays at once.
1100 <entry spanname="col2_on">
1108 <entry spanname="col3_on">
1117 <entry spanname="col4_on">
1119 <function>Unwilling</function>
1120 not received by the display.
1133 <entry spanname="col5_on">
1134 Display fails to receive
1135 <function>Unwilling .</function>
1143 <entry spanname="col4_on">
1153 <entry spanname="col5_on">
1154 The display should continue to send
1155 <function>Query</function>
1156 messages until a response is received.
1162 <entry spanname="col2_on">
1163 Timeout/Retransmission policy:
1170 <entry spanname="col3_on">
1171 Like all packets sent from the manager to the display, this packet should
1172 never be retransmitted.
1176 <entry spanname="col1_on">
1177 <function>Request</function>
1183 <entry spanname="col2_on">
1185 Display -> Manager
1196 <entry spanname="col3_on">
1197 <emphasis remap='I'>Display Number</emphasis>: CARD16
1205 <entry spanname="col4_on">
1206 Specifies the index of this particular server for the host
1207 on which the display is resident.
1208 This value will be zero for most autonomous displays.
1215 <entry spanname="col3_on">
1216 <emphasis remap='I'>Connection Types</emphasis>: ARRAY16
1224 <entry spanname="col4_on">
1225 Specifies an array indicating the stream services accepted by the display.
1226 If the high-order byte in a particular entry is zero, the low-order byte
1227 corresponds to an X-protocol host family type.
1234 <entry spanname="col3_on">
1235 <emphasis remap='I'>Connection Addresses</emphasis>: ARRAYofARRAY8
1243 <entry spanname="col4_on">
1244 For each connection type in the previous array, the corresponding entry in
1245 this array indicates the network address of the display device.
1252 <entry spanname="col3_on">
1254 <emphasis remap='I'>Authentication Name</emphasis>: ARRAY8
1257 <emphasis remap='I'>Authentication Data</emphasis>: ARRAY8
1266 <entry spanname="col4_on">
1267 Specifies the authentication protocol that the display expects
1268 the manager to validate itself with. The Authentication Data is
1269 expected to contain data that the manager will interpret, modify
1270 and use to authenticate itself.
1277 <entry spanname="col3_on">
1278 <emphasis remap='I'>Authorization Names</emphasis>: ARRAYofARRAY8
1286 <entry spanname="col4_on">
1287 Specifies which types of authorization the display supports. The
1288 manager may decide to reject displays with which it cannot perform
1296 <entry spanname="col3_on">
1297 <emphasis remap='I'>Manufacturer Display ID</emphasis>: ARRAY8
1305 <entry spanname="col4_on">
1306 Can be used by the manager to determine how to decrypt the
1307 Authentication Data field in this packet. See the section below on
1308 Manufacturer Display ID Format.
1314 <entry spanname="col2_on">
1322 <entry spanname="col3_on">
1324 <function>Request</function>
1325 packet is sent by a display to a specific host to request a
1326 session ID in preparation for a establishing a connection. If the manager
1327 is willing to service a connection to this display, it should return an
1328 <function>Accept</function>
1329 packet with a valid session ID and should be ready for a subsequent
1330 <function>Manage</function>
1331 request. Otherwise, it should return a
1332 <function>Decline</function>
1339 <entry spanname="col2_on">
1347 <entry spanname="col3_on">
1348 <function>Accept ,</function>
1349 <function>Decline</function>
1355 <entry spanname="col2_on">
1363 <entry spanname="col3_on">
1372 <entry spanname="col4_on">
1373 Request not received by manager.
1381 <entry spanname="col4_on">
1391 <entry spanname="col5_on">
1392 Display timeout waiting for response.
1400 <entry spanname="col4_on">
1410 <entry spanname="col5_on">
1412 <function>Request</function>
1422 <entry spanname="col4_on">
1432 <entry spanname="col5_on">
1433 Message received out of order by manager.
1441 <entry spanname="col4_on">
1451 <entry spanname="col5_on">
1460 <entry spanname="col4_on">
1470 <entry spanname="col5_on">
1472 <function>Request</function>
1473 is sent, the manager sends the Session ID
1474 associated with the next session in the
1475 <function>Accept .</function>
1476 If that next session is not yet started,
1477 the manager will simply resend with the same Session ID.
1478 If the session is in progress, the manager will reply
1479 with a new Session ID; in which case, the
1480 <function>Accept</function>
1481 will be discarded by the display.
1487 <entry spanname="col2_on">
1488 Timeout/Retransmission policy:
1495 <entry spanname="col3_on">
1496 Timeout after 2 seconds, exponential backoff to 32 seconds.
1497 After no more than 126 seconds, give up and report an error to the user.
1502 <entry spanname="col1_on">
1503 <function>Accept</function>
1509 <entry spanname="col2_on">
1511 Manager -> Display
1522 <entry spanname="col3_on">
1523 <emphasis remap='I'>Session ID</emphasis>: CARD32
1531 <entry spanname="col4_on">
1532 Identifies the session that can be started by the manager.
1539 <entry spanname="col3_on">
1541 <emphasis remap='I'>Authentication Name</emphasis>: ARRAY8
1544 <emphasis remap='I'>Authentication Data</emphasis>: ARRAY8
1553 <entry spanname="col4_on">
1554 Is the data sent back to the display to authenticate the manager.
1555 If the Authentication Data is not the value expected by the display, it
1556 should terminate the protocol at this point and display an error to the user.
1563 <entry spanname="col3_on">
1565 <emphasis remap='I'>Authorization Name</emphasis>: ARRAY8
1568 <emphasis remap='I'>Authorization Data</emphasis>: ARRAY8
1577 <entry spanname="col4_on">
1578 Is the data sent to the display to indicate the type of authorization the
1579 manager will be using in the first call to
1580 <function>XOpenDisplay</function>
1582 <function>Manage</function>
1590 <entry spanname="col2_on">
1598 <entry spanname="col3_on">
1601 <function>Accept</function>
1602 packet is sent by a manager in response to a
1603 <function>Request</function>
1604 packet if the manager is willing to establish a connection for the display.
1605 The Session ID is used to identify this connection from any preceding
1606 ones and will be used by the display in its subsequent
1607 <function>Manage</function>
1609 The Session ID is a 32-bit number that is incremented each time an
1610 <function>Accept</function>
1611 packet is sent as it must be unique over a reasonably long period of time.
1614 If the authentication information is invalid, a
1615 <function>Decline</function>
1616 packet will be returned with an appropriate
1617 <function>Status</function>
1625 <entry spanname="col2_on">
1633 <entry spanname="col3_on">
1642 <entry spanname="col4_on">
1643 <function>Accept</function>
1645 <function>Decline</function>
1646 not received by display.
1654 <entry spanname="col4_on">
1664 <entry spanname="col5_on">
1665 Display timeout waiting for response to
1666 <function>Request .</function>
1674 <entry spanname="col4_on">
1684 <entry spanname="col5_on">
1686 <function>Request</function>
1694 <entry spanname="col3_on">
1703 <entry spanname="col4_on">
1704 Message received out of order by display.
1712 <entry spanname="col4_on">
1722 <entry spanname="col5_on">
1724 <function>Accept</function>
1726 <function>Manage</function>
1735 <entry spanname="col4_on">
1745 <entry spanname="col5_on">
1747 <function>Accept</function>
1748 messages after it has sent a
1749 <function>Manage</function>
1756 <entry spanname="col2_on">
1757 Timeout/Retransmission policy:
1764 <entry spanname="col3_on">
1765 Like all packets sent from the manager to the display, this packet should
1766 never be retransmitted.
1771 <entry spanname="col1_on">
1772 <function>Decline</function>
1778 <entry spanname="col2_on">
1780 Manager -> Display
1791 <entry spanname="col3_on">
1792 <emphasis remap='I'>Status</emphasis>: ARRAY8
1800 <entry spanname="col4_on">
1801 Is a human readable string indicating the reason for refusal of
1809 <entry spanname="col3_on">
1811 <emphasis remap='I'>Authentication Name</emphasis>:
1815 <emphasis remap='I'>Authentication Data</emphasis>:
1825 <entry spanname="col4_on">
1826 Is the data sent back to the display to authenticate the manager. If the
1827 Authentication Data is not the value expected by the display, it
1828 should terminate the protocol at this point and display an error to the user.
1834 <entry spanname="col2_on">
1842 <entry spanname="col3_on">
1844 <function>Decline</function>
1845 packet is sent by a manager in response to a
1846 <function>Request</function>
1847 packet if the manager is unwilling to establish a connection for the
1849 This is allowed even if the manager had responded
1850 <function>Willing</function>
1851 to a previous query.
1857 <entry spanname="col2_on">
1865 <entry spanname="col3_on">
1867 <function>Accept .</function>
1873 <entry spanname="col2_on">
1874 Timeout/Retransmission policy:
1881 <entry spanname="col3_on">
1882 Like all packets sent from a manager to a display, this packet should never
1888 <entry spanname="col1_on">
1889 <function>Manage</function>
1895 <entry spanname="col2_on">
1897 Display -> Manager
1908 <entry spanname="col3_on">
1909 <emphasis remap='I'>Session ID</emphasis>: CARD32
1917 <entry spanname="col4_on">
1918 Should contain the nonzero session ID returned in the
1919 <function>Accept</function>
1927 <entry spanname="col3_on">
1928 <emphasis remap='I'>Display Number</emphasis>: CARD16
1936 <entry spanname="col4_on">
1937 Must match the value sent in the previous
1938 <function>Request</function>
1946 <entry spanname="col3_on">
1947 <emphasis remap='I'>Display Class</emphasis>: ARRAY8
1955 <entry spanname="col4_on">
1956 Specifies the class of the display.
1957 See the Display Class Format section,
1958 which discusses the format of this field.
1965 <entry spanname="col2_on">
1973 <entry spanname="col3_on">
1975 <function>Manage</function>
1976 packet is sent by a display to ask the manager to begin a
1977 session on the display. If the Session ID is correct the manager
1978 should open a connection; otherwise, it should respond with a
1979 <function>Refuse</function>
1981 <function>Failed</function>
1982 packet, unless the Session ID matches a currently
1983 running session or a session that has not yet successfully opened the
1984 display but has not given up the attempt. In this latter case, the
1985 <function>Manage</function>
1986 packet should be ignored.
1987 This will work as stream connections give positive success indication
1988 to both halves of the stream, and positive failure indication
1989 to the connection initiator (which will eventually generate a
1990 <function>Failed</function>
1997 <entry spanname="col2_on">
2005 <entry spanname="col3_on">
2006 X connection with correct auth info,
2007 <function>Refuse ,</function>
2008 <function>Failed .</function>
2014 <entry spanname="col2_on">
2022 <entry spanname="col3_on">
2031 <entry spanname="col4_on">
2032 <function>Manage</function>
2033 not received by manager.
2041 <entry spanname="col4_on">
2051 <entry spanname="col5_on">
2052 Display timeout waiting for response.
2060 <entry spanname="col4_on">
2070 <entry spanname="col5_on">
2072 <function>Manage</function>
2081 <entry spanname="col3_on">
2090 <entry spanname="col4_on">
2091 <function>Manage</function>
2092 received out of order by manager.
2100 <entry spanname="col4_on">
2110 <entry spanname="col5_on">
2111 Session already in progress with matching Session ID.
2119 <entry spanname="col4_on">
2129 <entry spanname="col5_on">
2130 <function>Manage</function>
2139 <entry spanname="col4_on">
2149 <entry spanname="col5_on">
2150 Session ID does not match next Session ID.
2158 <entry spanname="col4_on">
2168 <entry spanname="col5_on">
2169 <function>Refuse</function>
2178 <entry spanname="col3_on">
2187 <entry spanname="col4_on">
2188 Display cannot be opened on selected stream.
2196 <entry spanname="col4_on">
2206 <entry spanname="col5_on">
2207 Display connection setup fails.
2215 <entry spanname="col4_on">
2225 <entry spanname="col5_on">
2226 <function>Failed</function>
2227 message is sent including a human readable reason.
2234 <entry spanname="col3_on">
2243 <entry spanname="col4_on">
2244 Display open does not succeed before a second manage packet is received
2245 because of a timeout occuring in the display.
2253 <entry spanname="col4_on">
2263 <entry spanname="col5_on">
2264 <function>Manage</function>
2265 packet received with Session ID matching the session
2266 attempting to connect to the display.
2274 <entry spanname="col4_on">
2284 <entry spanname="col5_on">
2285 <function>Manage</function>
2286 packet is ignored. As the stream connection will either
2287 succeed, which will result in an active session, or the stream will
2288 eventually give up hope of connecting and send a
2289 <function>Failed</function>
2290 packet; no response to this
2291 <function>Manage</function>
2292 packet is necessary.
2298 <entry spanname="col2_on">
2299 Timeout/Retransmission policy:
2306 <entry spanname="col3_on">
2307 Timeout after 2 seconds, exponential backoff to 32 seconds. After no more
2308 than 126 seconds, give up and report an error to the user.
2313 <entry spanname="col1_on">
2314 <function>Refuse</function>
2320 <entry spanname="col2_on">
2322 Manager -> Display
2333 <entry spanname="col3_on">
2334 <emphasis remap='I'>Session ID</emphasis>: CARD32
2342 <entry spanname="col4_on">
2343 Should be set to the Session ID received in the
2344 <function>Manage</function>
2352 <entry spanname="col2_on">
2360 <entry spanname="col3_on">
2362 <function>Refuse</function>
2363 packet is sent by a manager when the Session ID received in the
2364 <function>Manage</function>
2365 packet does not match the current Session ID.
2366 The display should assume that it received an old
2367 <function>Accept</function>
2368 packet and should resend its
2369 <function>Request</function>
2376 <entry spanname="col2_on">
2384 <entry spanname="col3_on">
2393 <entry spanname="col4_on">
2394 Error message is lost.
2402 <entry spanname="col4_on">
2412 <entry spanname="col5_on">
2413 Display times out waiting for
2415 <function>Refuse</function>
2417 <function>Failed .</function>
2425 <entry spanname="col4_on">
2435 <entry spanname="col5_on">
2437 <function>Manage</function>
2446 <entry spanname="col2_on">
2447 Timeout/Retransmission policy:
2454 <entry spanname="col3_on">
2455 Like all packets sent from a manager to a display, this packet should never be
2461 <entry spanname="col1_on">
2462 <function>Failed</function>
2468 <entry spanname="col2_on">
2470 Manager -> Display
2481 <entry spanname="col3_on">
2482 <emphasis remap='I'>Session ID</emphasis>: CARD32
2490 <entry spanname="col4_on">
2491 Should be set to the Session ID received in the
2492 <function>Manage</function>
2500 <entry spanname="col3_on">
2501 <emphasis remap='I'>Status</emphasis>: ARRAY8
2509 <entry spanname="col4_on">
2510 Is a human readable string indicating the reason for failure.
2517 <entry spanname="col2_on">
2525 <entry spanname="col3_on">
2527 <function>Failed</function>
2528 packet is sent by a manager when it has problems establishing
2529 the initial X connection in response to the
2530 <function>Manage</function>
2537 <entry spanname="col2_on">
2545 <entry spanname="col3_on">
2547 <function>Refuse .</function>
2552 <entry spanname="col1_on">
2553 <function>KeepAlive</function>
2559 <entry spanname="col2_on">
2561 Display -> Manager
2572 <entry spanname="col3_on">
2573 <emphasis remap='I'>Display Number</emphasis>: CARD16
2581 <entry spanname="col4_on">
2582 Set to the display index for the display host.
2589 <entry spanname="col3_on">
2590 <emphasis remap='I'>Session ID</emphasis>: CARD32
2598 <entry spanname="col4_on">
2599 Should be set to the Session ID received in the
2600 <function>Manage</function>
2601 packet during the negotiation for the current session.
2607 <entry spanname="col2_on">
2615 <entry spanname="col3_on">
2618 <function>KeepAlive</function>
2619 packet can be sent at any time during the session by a
2620 display to discover if the manager is running.
2621 The manager should respond with
2622 <function>Alive</function>
2623 whenever it receives this type of packet.
2626 This allows the display to discover when the manager host
2627 is no longer running.
2628 A display is not required to send
2629 <function>KeepAlive</function>
2630 packets and, upon lack of receipt of
2631 <function>Alive</function>
2632 packets, is not required to perform any specific action.
2635 The expected use of this packet is to terminate an active session when the
2636 manager host or network link fails. The display should keep track of the
2637 time since any packet has been received from the manager host and use
2638 <function>KeepAlive</function>
2639 packets when a substantial time has elapsed since the
2647 <entry spanname="col2_on">
2655 <entry spanname="col3_on">
2656 <function>Alive</function>
2662 <entry spanname="col2_on">
2670 <entry spanname="col3_on">
2679 <entry spanname="col4_on">
2680 Manager does not receive the packet or display does not receive the response.
2689 <entry spanname="col4_on">
2699 <entry spanname="col5_on">
2701 <function>Alive</function>
2710 <entry spanname="col4_on">
2720 <entry spanname="col5_on">
2721 Retransmit the packet with an exponential backoff; start at 2 seconds and
2722 assume the host is not up after no less than 30 seconds.
2727 <entry spanname="col1_on">
2728 <function>Alive</function>
2734 <entry spanname="col2_on">
2736 Manager -> Display
2747 <entry spanname="col3_on">
2748 <emphasis remap='I'>Session Running</emphasis>: CARD8
2756 <entry spanname="col4_on">
2757 Indicates that the session identified by Session ID is
2758 currently active. The value is zero if no session is active
2767 <entry spanname="col3_on">
2768 <emphasis remap='I'>Session ID</emphasis>: CARD32
2776 <entry spanname="col4_on">
2777 Specifies the ID of the currently running session; if any.
2778 When no session is active this field should be zero.
2785 <entry spanname="col2_on">
2793 <entry spanname="col3_on">
2795 <function>Alive</function>
2796 packet is sent in response to a
2797 <function>KeepAlive</function>
2799 If a session is currently active on the display, the manager includes the
2800 Session ID in the packet. The display can use this information to
2801 determine the status of the manager.
2810 <sect1 id="Session_Termination">
2811 <title>Session Termination</title>
2813 When the session is over, the initial connection with the display (the one
2814 that acknowledges the
2815 <function>Manage</function>
2816 packet) will be closed by the manager.
2817 If only a single session was active on the display,
2818 all other connections should be closed by the display
2819 and the display should be reset. If multiple sessions
2820 are active simultaneously and the display can identify which connections
2821 belong to the terminated sesssion, those connections should be closed.
2822 Otherwise, all connections should be closed and the display reset only when
2823 all sessions have been terminated (that is, all initial connections closed).
2827 The session may also be terminated at any time by the display if the
2828 managing host no longer responds to
2829 <function>KeepAlive</function>
2831 The exact time-outs for sending
2832 <function>KeepAlive</function>
2833 packets is not specified in this protocol as the trade off
2834 should not be fixed between loading an otherwise idle system with spurious
2835 <function>KeepAlive</function>
2836 packets and not noticing that the manager host is down for a long time.
2840 <sect1 id="State_Diagrams">
2841 <title>State Diagrams</title>
2843 <!-- (SN State Diagrams -->
2847 The following state diagrams are designed to cover all actions of both
2848 the display and the manager. Any packet that is received out-of-sequence
2858 <term><emphasis remap='I'>start</emphasis>:</term>
2861 User-requested connect to one host -> <emphasis remap='I'>query</emphasis>
2864 User-requested connect to some host -> <emphasis remap='I'>broadcast</emphasis>
2867 User-requested connect to site host-list -> <emphasis remap='I'>indirect</emphasis>
2872 <term><emphasis remap='I'>query</emphasis>:</term>
2875 Send <function>Query</function> packet
2876 -> <emphasis remap='I'>collect-query</emphasis>
2881 <term><emphasis remap='I'>collect-query</emphasis>:</term>
2884 Receive <function>Willing</function> ->
2885 <emphasis remap='I'>start-connection</emphasis>
2888 Receive <function>Unwilling</function> ->
2889 <emphasis remap='I'>stop-connection</emphasis>
2892 Timeout -> <emphasis remap='I'>query</emphasis>
2898 <term><emphasis remap='I'>broadcast</emphasis>:</term>
2901 Send <function>BroadcastQuery</function> packet
2904 -> <emphasis remap='I'>collect-broadcast-query</emphasis>
2909 <term><emphasis remap='I'>collect-broadcast-query</emphasis>:</term>
2912 Receive <function>Willing</function> ->
2913 <emphasis remap='I'>update-broadcast-willing</emphasis>
2916 User-requested connect to one host ->
2917 <emphasis remap='I'>start-connection</emphasis>
2920 Timeout -> <emphasis remap='I'>broadcast</emphasis>
2925 <term><emphasis remap='I'>update-broadcast-willing</emphasis>:</term>
2928 Add new host to the host list presented to the user
2931 -> <emphasis remap='I'>collect-broadcast-query</emphasis>
2936 <term><emphasis remap='I'>indirect</emphasis>:</term>
2939 Send <function>IndirectQuery</function> packet
2942 -> <emphasis remap='I'>collect-indirect-query</emphasis>
2947 <term><emphasis remap='I'>collect-indirect-query</emphasis>:</term>
2950 Receive <function>Willing</function> ->
2951 <emphasis remap='I'>update-indirect-willing</emphasis>
2954 User-requested connect to one host ->
2955 <emphasis remap='I'>start-connection</emphasis>
2958 Timeout -> <emphasis remap='I'>indirect</emphasis>
2963 <term><emphasis remap='I'>update-indirect-willing</emphasis>:</term>
2966 Add new host to the host list presented to the user
2969 -> <emphasis remap='I'>collect-indirect-query</emphasis>
2975 <term><emphasis remap='I'>start-connection</emphasis>:</term>
2978 Send <function>Request</function> packet
2981 -> <emphasis remap='I'>await-request-response</emphasis>
2986 <term><emphasis remap='I'>await-request-response</emphasis>:</term>
2989 Receive <function>Accept</function> ->
2990 <emphasis remap='I'>manage</emphasis>
2993 Receive <function>Decline</function> ->
2994 <emphasis remap='I'>stop-connection</emphasis>
2997 Timeout -> <emphasis remap='I'>start-connection</emphasis>
3002 <term><emphasis remap='I'>manage</emphasis>:</term>
3008 Send <function>Manage</function> packet with Session ID
3011 -> <emphasis remap='I'>await-manage-response</emphasis>
3016 <term><emphasis remap='I'>await-manage-response</emphasis>:</term>
3019 Receive <function>XOpenDisplay :</function> ->
3020 <emphasis remap='I'>run-session</emphasis>
3023 Receive <function>Refuse</function> with matching Session ID
3024 -> <emphasis remap='I'>start-connection</emphasis>
3027 Receive <function>Failed</function> with matching Session ID
3028 -> <emphasis remap='I'>stop-connection</emphasis>
3031 Timeout -> <emphasis remap='I'>manage</emphasis>
3036 <term><emphasis remap='I'>stop-connection</emphasis>:</term>
3039 Display cause of termination to user
3042 -> <emphasis remap='I'>start</emphasis>
3047 <term><emphasis remap='I'>run-session</emphasis>:</term>
3050 Decide to send <function>KeepAlive</function> packet ->
3051 <emphasis remap='I'>keep-alive</emphasis>
3054 wait close of first display connection
3057 -> <emphasis remap='I'>reset-display</emphasis>
3062 <term><emphasis remap='I'>keep-alive</emphasis>:</term>
3065 Send <function>KeepAlive</function> packet with current Session ID
3068 -> <emphasis remap='I'>await-alive</emphasis>
3073 <term><emphasis remap='I'>await-alive</emphasis>:</term>
3076 Receive <function>Alive</function> with matching Session ID ->
3077 <emphasis remap='I'>run-session</emphasis>
3080 Receive <function>Alive</function> with nonmatching Session ID
3081 or FALSE Session Running -> <emphasis remap='I'>reset-display</emphasis>
3084 Final timeout without receiving <function>Alive</function>
3085 packet -> <emphasis remap='I'>reset-display</emphasis>
3088 Timeout -> <emphasis remap='I'>keep-alive</emphasis>
3093 <term><emphasis remap='I'>reset-display</emphasis>:</term>
3096 (if possible) -> close all display connections associated with this session
3099 Last session -> close all display connections
3102 -> <emphasis remap='I'>start</emphasis>
3115 <term><emphasis remap='I'>idle</emphasis>:</term>
3118 Receive <function>Query</function> ->
3119 <emphasis remap='I'>query-respond</emphasis>
3123 <function>BroadcastQuery</function>
3124 -> <emphasis remap='I'>broadcast-respond</emphasis>
3128 <function>IndirectQuery</function>
3129 -> <emphasis remap='I'>indirect-respond</emphasis>
3133 <function>ForwardQuery</function>
3134 -> <emphasis remap='I'>forward-respond</emphasis>
3138 <function>Request</function>
3139 -> <emphasis remap='I'>request-respond</emphasis>
3143 <function>Manage</function>
3144 -> <emphasis remap='I'>manage</emphasis>
3147 An active session terminates
3148 -> <emphasis remap='I'>finish-session</emphasis>
3151 Receive <function>KeepAlive</function>
3152 -> <emphasis remap='I'>send-alive</emphasis>
3155 -> <emphasis remap='I'>idle</emphasis>
3160 <term><emphasis remap='I'>query-respond</emphasis>:</term>
3163 If willing to manage -> <emphasis remap='I'>send-willing</emphasis>
3166 -> <emphasis remap='I'>send-unwilling</emphasis>
3171 <term><emphasis remap='I'>broadcast-respond</emphasis>:</term>
3174 If willing to manage -> <emphasis remap='I'>send-willing</emphasis>
3177 -> <emphasis remap='I'>idle</emphasis>
3182 <term><emphasis remap='I'>indirect-respond</emphasis>:</term>
3185 Send <function>ForwardQuery</function>
3186 packets to all managers on redirect list
3189 If willing to manage -> <emphasis remap='I'>send-willing</emphasis>
3192 -> <emphasis remap='I'>idle</emphasis>
3197 <term><emphasis remap='I'>forward-respond</emphasis>:</term>
3200 Decode destination address, if willing to manage ->
3201 <emphasis remap='I'>send-willing</emphasis>
3204 -> <emphasis remap='I'>idle</emphasis>
3209 <term><emphasis remap='I'>send-willing</emphasis>:</term>
3212 Send <function>Willing</function> packet
3215 -> <emphasis remap='I'>idle</emphasis>
3220 <term><emphasis remap='I'>send-unwilling</emphasis>:</term>
3223 Send <function>Unwilling</function> packet
3224 -> <emphasis remap='I'>idle</emphasis>
3229 <term><emphasis remap='I'>request-respond</emphasis>:</term>
3232 If manager is willing to allow a session on display
3233 -> <emphasis remap='I'>accept-session</emphasis>
3236 -> <emphasis remap='I'>decline-session</emphasis>
3241 <term><emphasis remap='I'>accept-session</emphasis>:</term>
3244 Generate Session ID and save Session ID, display address, and
3245 display number somewhere
3248 Send <function>Accept</function> packet
3251 -> <emphasis remap='I'>idle</emphasis>
3256 <term><emphasis remap='I'>decline-session</emphasis>:</term>
3259 Send <function>Decline</function> packet
3262 -> <emphasis remap='I'>idle</emphasis>
3267 <term><emphasis remap='I'>manage</emphasis>:</term>
3270 If Session ID matches saved Session ID ->
3271 <emphasis remap='I'>run-session</emphasis>
3274 If Session ID matches Session ID of session in process of
3275 starting up, or currently active session ->
3276 <emphasis remap='I'>idle</emphasis>
3279 -> <emphasis remap='I'>refuse</emphasis>
3284 <term><emphasis remap='I'>refuse</emphasis>:</term>
3287 Send <function>Refuse</function> packet
3290 -> <emphasis remap='I'>idle</emphasis>
3295 <term><emphasis remap='I'>run-session</emphasis>:</term>
3298 Terminate any session in progress
3301 <function>XOpenDisplay</function>
3304 Open display succeeds ->
3305 <emphasis remap='I'>start-session</emphasis>
3308 -> <emphasis remap='I'>failed</emphasis>
3313 <term><emphasis remap='I'>failed</emphasis>:</term>
3316 Send <function>Failed</function> packet
3319 -> <emphasis remap='I'>idle</emphasis>
3324 <term><emphasis remap='I'>start-session</emphasis>:</term>
3330 -> <emphasis remap='I'>idle</emphasis>
3335 <term><emphasis remap='I'>finish-session</emphasis>:</term>
3338 <function>XCloseDisplay</function>
3341 -> <emphasis remap='I'>idle</emphasis>
3346 <term><emphasis remap='I'>send-alive</emphasis>:</term>
3349 Send <function>Alive</function> packet containing current status
3352 -> <emphasis remap='I'>idle</emphasis>
3360 <sect1 id="Protocol_Encoding">
3361 <title>Protocol Encoding</title>
3363 When XDMCP is implemented on top of the Internet User Datagram Protocol (UDP),
3364 port number 177 is to be used. When using UDP over IPv4, Broadcast Query
3365 packets are sent via UDP broadcast. When using UDP over IPv6, Broadcast Query
3366 packets are sent via multicast, either to an address in the IANA registered
3367 XDMCP multicast address range of
3368 FF0<emphasis remap='I'>X</emphasis>:0:0:0:0:0:0:12B
3369 (where the <emphasis remap='I'>X</emphasis> is replaced by a valid scope id)
3370 or to a locally assigned
3371 multicast address. The version number in all packets will be 1.
3372 Packet opcodes are 16-bit integers.
3375 <informaltable frame="none">
3376 <tgroup cols='2' align='left'>
3377 <colspec colname='c1' colsep="0"/>
3378 <colspec colname='c2' colsep="0"/>
3381 <entry>Packet Name</entry>
3382 <entry>Encoding</entry>
3387 <entry>BroadcastQuery</entry>
3391 <entry>Query</entry>
3395 <entry>IndirectQuery</entry>
3399 <entry>ForwardQuery</entry>
3403 <entry>Willing</entry>
3407 <entry>Unwilling</entry>
3411 <entry>Request</entry>
3415 <entry>Accept</entry>
3419 <entry>Decline</entry>
3423 <entry>Manage</entry>
3427 <entry>Refuse</entry>
3431 <entry>Failed</entry>
3435 <entry>KeepAlive</entry>
3438 A previous version of this document incorrectly reversed the opcodes of
3439 <emphasis role="bold">Alive</emphasis> and
3440 <emphasis role="bold">KeepAlive</emphasis>.
3445 <entry>Alive</entry>
3448 A previous version of this document incorrectly reversed the opcodes of
3449 <emphasis role="bold">Alive</emphasis> and
3450 <emphasis role="bold">KeepAlive</emphasis>.
3459 Per packet information follows:
3463 <function>Query</function>,
3464 <function>BroadcastQuery</function>,
3465 <function>IndirectQuery</function>
3468 <literallayout class="monospaced">
3469 2 CARD16 version number (always 1)
3470 2 CARD16 opcode (always Query, BroadcastQuery or IndirectQuery)
3472 1 CARD8 number of Authentication Names sent (m)
3473 2 CARD16 length of first Authentication Name (m<emphasis role="subscript">1</emphasis>)
3474 m<emphasis role="subscript">1</emphasis> CARD8 first Authentication Name
3475 ... Other Authentication Names
3479 Note that these three packets are identical except for the opcode field.
3482 <literallayout class="monospaced">
3483 <function>ForwardQuery</function>
3484 2 CARD16 version number (always 1)
3485 2 CARD16 opcode (always ForwardQuery)
3487 2 CARD16 length of Client Address (m)
3488 m CARD8 Client Address
3489 2 CARD16 length of Client Port (n)
3491 1 CARD8 number of Authentication Names sent (o)
3492 2 CARD16 length of first Authentication Name (o<emphasis role="subscript">1</emphasis>)
3493 o<emphasis role="subscript">1</emphasis> CARD8 first Authentication Name
3494 ... Other Authentication Names
3497 <literallayout class="monospaced">
3498 <function>Willing</function>
3499 2 CARD16 version number (always 1)
3500 2 CARD16 opcode (always Willing)
3501 2 CARD16 length (6 + m + n + o)
3502 2 CARD16 Length of Authentication Name (m)
3503 m CARD8 Authentication Name
3504 2 CARD16 Hostname length (n)
3506 2 CARD16 Status length (o)
3510 <literallayout class="monospaced">
3511 <function>Unwilling</function>
3512 2 CARD16 version number (always 1)
3513 2 CARD16 opcode (always Unwilling)
3514 2 CARD16 length (4 + m + n)
3515 2 CARD16 Hostname length (m)
3517 2 CARD16 Status length (n)
3521 <literallayout class="monospaced">
3522 <function>Request</function>
3523 2 CARD16 version number (always 1)
3524 2 CARD16 opcode (always Request)
3526 2 CARD16 Display Number
3527 1 CARD8 Count of Connection Types (m)
3528 2xm CARD16 Connection Types
3529 1 CARD8 Count of Connection Addresses (n)
3530 2 CARD16 Length of first Connection Address (n<emphasis role="subscript">1</emphasis>)
3531 n<emphasis role="subscript">1</emphasis> CARD8 First Connection Address
3532 ... Other connection addresses
3533 2 CARD16 Length of Authentication Name (o)
3534 o CARD8 Authentication Name
3535 2 CARD16 Length of Authentication Data (p)
3536 p CARD8 Authentication Data
3537 1 CARD8 Count of Authorization Names (q)
3538 2 CARD16 Length of first Authorization Name (q<emphasis role="subscript">1</emphasis>)
3539 q<emphasis role="subscript">1</emphasis> CARD8 First Authorization Name
3540 ... Other authorization names
3541 2 CARD16 Length of Manufacturer Display ID (r)
3542 r CARD8 Manufacturer Display ID
3545 <literallayout class="monospaced">
3546 <function>Accept</function>
3547 2 CARD16 version number (always 1)
3548 2 CARD16 opcode (always Accept)
3549 2 CARD16 length (12 + n + m + o + p)
3551 2 CARD16 Length of Authentication Name (n)
3552 n CARD8 Authentication Name
3553 2 CARD16 Length of Authentication Data (m)
3554 m CARD8 Authentication Data
3555 2 CARD16 Length of Authorization Name (o)
3556 o CARD8 Authorization Name
3557 2 CARD16 Length of Authorization Data (p)
3558 p CARD8 Authorization Data
3561 <literallayout class="monospaced">
3562 <function>Decline</function>
3563 2 CARD16 version number (always 1)
3564 2 CARD16 opcode (always Decline)
3565 2 CARD16 length (6 + m + n + o)
3566 2 CARD16 Length of Status (m)
3568 2 CARD16 Length of Authentication Name (n)
3569 n CARD8 Authentication Name
3570 2 CARD16 Length of Authentication Data (o)
3571 o CARD8 Authentication Data
3574 <literallayout class="monospaced">
3575 <function>Manage</function>
3576 2 CARD16 version number (always 1)
3577 2 CARD16 opcode (always Manage)
3578 2 CARD16 length (8 + m)
3580 2 CARD16 Display Number
3581 2 CARD16 Length of Display Class (m)
3582 m CARD8 Display Class
3585 <literallayout class="monospaced">
3586 <function>Refuse</function>
3587 2 CARD16 version number (always 1)
3588 2 CARD16 opcode (always Refuse)
3593 <literallayout class="monospaced">
3594 <function>Failed</function>
3595 2 CARD16 version number (always 1)
3596 2 CARD16 opcode (always Failed)
3597 2 CARD16 length (6 + m)
3599 2 CARD16 Length of Status (m)
3603 <literallayout class="monospaced">
3604 <function>KeepAlive</function>
3605 2 CARD16 version number (always 1)
3606 2 CARD16 opcode (always KeepAlive)
3608 2 CARD16 Display Number
3612 <literallayout class="monospaced">
3613 <function>Alive</function>
3614 2 CARD16 version number (always 1)
3615 2 CARD16 opcode (always Alive)
3617 1 CARD8 Session Running (0: not running 1: running)
3618 4 CARD32 Session ID (0: not running)
3622 <sect1 id="Display_Class_Format">
3623 <title>Display Class Format</title>
3625 <!-- (SN Display Class Format -->
3628 The Display Class field of the
3629 <function>Manage</function>
3630 packet is used by the display manager to collect common sorts of
3631 displays into manageable groups. This field is a string encoded of
3632 ISO-LATIN-1 characters in the following format:
3635 <literallayout class="monospaced">
3636 <emphasis remap='I'>ManufacturerID</emphasis>-<emphasis remap='I'>ModelNumber</emphasis>
3640 Both elements of this string must exclude characters of the set
3641 { <function>-</function>,
3642 <function>.</function>,
3643 <function>:</function>,
3644 <function>*</function>,
3645 <function>?</function>,
3646 <emphasis remap='I'><space></emphasis> }.
3647 The ManufacturerID is a string that should be registered
3648 with the X Consortium.
3649 The ModelNumber is designed to identify characteristics of the display
3650 within the manufacturer's product line.
3651 This string should be documented in the users manual for the
3652 particular device and should probably not be specifiable by the
3653 display user to avoid unexpected configuration errors.
3657 <sect1 id="Manufacturer_Display_ID_Format">
3658 <title>Manufacturer Display ID Format</title>
3660 <!-- (SN Manufacturer Display ID Format -->
3663 To authenticate the manager, the display and manager will share a private
3665 The manager, then, must be able to discover which key to use for a
3667 The Manufacturer Display ID field of the
3668 <function>Request</function>
3669 packet is intended for this purpose. Typically, the manager host will
3670 contain a map between this number and the key. This field is intended to be
3671 unique per display, possibly the ethernet address of the display in the form:
3674 <literallayout class="monospaced">
3675 -Ethernet-8:0:2b:a:f:d2
3679 It can also be a string of the form:
3682 <literallayout class="monospaced">
3683 <emphasis remap='I'>ManufacturerID</emphasis>-<emphasis remap='I'>ModelNumber</emphasis>-<emphasis remap='I'>SerialNumber</emphasis>
3687 The ManufacturerID, ModelNumber and SerialNumber are encoded using
3688 ISO-LATIN-1 characters, excluding {
3689 <function>-</function>,
3690 <function>.</function>,
3691 <function>*</function>,
3692 <function>?</function>,
3693 <emphasis remap='I'><space></emphasis> }
3697 When the display is shipped to a customer, it should include both the
3698 Manufacturer Display ID and the private key in the documentation set.
3699 This information should not be modifiable by the display user.
3704 <sect1 id="Authentication">
3705 <title>Authentication</title>
3707 <!-- (SN Authentication -->
3710 In an environment where authentication is not needed, XDMCP can disable
3711 authentication by having the display send empty Authentication Name
3712 and Authentication Data fields in the
3713 <function>Request</function>
3715 In this case, the manager will not attempt to authenticate itself.
3716 Other authentication protocols may be developed, depending on local needs.
3720 In an unsecure environment, the display must be able to verify that the
3721 source of the various packets is a trusted manager. These packets will
3722 contain authentication information. As an example of such a system, the
3723 following discussion describes the "XDM-AUTHENTICATION-1" authentication
3724 system. This system uses a 56-bit shared private key, and 64 bits of
3725 authentication data. An associated example X authorization protocol
3726 "XDM-AUTHORIZATION-1" will also be discussed. The 56-bit key is represented
3727 as a 64-bit number in network order (big endian). This means that the first
3728 octet in the representation will be zero. When incrementing a 64-bit value,
3729 the 8 octets of data will be interpreted in network order (big endian).
3730 That is, the last octet will be incremented, subsequent carries propogate
3731 towards the first octet.
3741 The display and manager share a private key. This key could be programmed
3742 into the display by the manufacturer and shipped with the unit. It must not
3743 be available from the display itself, but should allow the value to be
3744 modified in some way. The system administrator would be responsible for
3745 managing a database of terminal keys.
3750 The display can generate random authentication numbers.
3756 Some definitions first:
3760 <!-- double chk math symbols, use mathml to display them? -->
3764 {D}= encryption of plain text D by key κ
3769 {Δ}*κ = decryption of crypto text Δ with key κ
3774 τ = private key shared by display and manager
3779 ρ = 64 bit random number generated by display
3784 α = authentication data in XDMCP packets
3789 σ = per-session private key, generated by manager
3794 β = authorization data
3800 Encryption will use the Data Encryption Standard (DES, FIPS 46-3); blocks
3801 shorter than 64 bits will be zero-filled
3802 on the right to 64 bits. Blocks longer than 64 bits will use block chaining:
3805 {D}κ = {D1 }κ {D2 xor {D1 }κ }κ
3809 The display generates the first authentication data in the
3810 <function>Request</function>
3815 αRequest = {ρ}τ
3820 For the <function>Accept</function>
3821 packet, the manager decrypts the initial message and returns
3827 ρ = {α Request } *τ
3831 α Accept = { ρ + 1}τ
3835 The <function>Accept</function>
3836 packet also contains the authorization intended for use by
3837 the X server. A description of authorization type "XDM-AUTHORIZATION-1"
3842 The <function>Accept</function>
3843 packet contains the authorization name
3844 "XDM-AUTHORIZATION-1". The authorization data is the string:
3851 To create authorization information for connection setup with the X server
3852 using the XDM-AUTHORIZATION-1 authorization protocol, the client computes the
3856 N mark = "X client identifier"
3859 T lineup = "Current time in seconds on client host (32 bits)"
3866 For TCP connections @N@ is 48 bits long and contains the 32-bit IPv4 address of
3867 the client host followed by the 16-bit port number of the client socket.
3868 Formats for other connections must be registered.
3869 The resulting value, β, is 192 bits of authorization data that is sent
3870 in the connection setup to the server. The server receives the packet,
3871 decrypts the contents. To accept the connection, the following must hold:
3877 ρ must match the value generated for the most recent XDMCP negotiation.
3882 T must be within 1200 seconds of the internally stored time. If no time
3883 been received before, the current time is set to @T@.
3888 No packet containing the same pair (N, T) can have been received
3889 in the last 1200 seconds (20 minutes).