1comm_wire(n)                 Remote communication                 comm_wire(n)
2
3
4
5______________________________________________________________________________
6

NAME

8       comm_wire - The comm wire protocol
9

SYNOPSIS

11       package require comm
12
13______________________________________________________________________________
14

DESCRIPTION

16       The  comm command provides an inter-interpreter remote execution facil‐
17       ity much like Tk's send(n), except that it uses sockets rather than the
18       X server for the communication path.  As a result, comm works with mul‐
19       tiple interpreters, works on Windows and Macintosh  systems,  and  pro‐
20       vides control over the remote execution path.
21
22       This  document  contains a specification of the various versions of the
23       wire protocol used by comm internally for the communication between its
24       endpoints. It has no relevance to users of comm, only to developers who
25       wish to modify the package, write a compatible facility in a  different
26       language, or some other facility based on the same protocol.
27

WIRE PROTOCOL VERSION 3

29   BASIC LAYER
30       The  basic encoding for all data is UTF-8. Because of this binary data,
31       including the NULL character, can be sent over the wire as is,  without
32       the need for armoring it.
33
34   BASIC MESSAGE LAYER
35       On  top of the Basic Layer we have a message oriented exchange of data.
36       The totality of all characters written to the channel is  a  Tcl  list,
37       with  each element a separate message, each itself a list. The messages
38       in the overall list are separated by EOL. Note that EOL characters  can
39       occur  within the list as well. They can be distinguished from the mes‐
40       sage-separating EOL by the fact that the data from the beginning up  to
41       their location is not a valid Tcl list.
42
43       EOL  is  signaled through the linefeed character, i.e LF, or, hex 0x0a.
44       This is following the unix convention for line-endings.
45
46       As a list each message is composed of words. Their meaning  depends  on
47       when the message was sent in the overall exchange. This is described in
48       the upcoming sections.
49
50   NEGOTIATION MESSAGES - INITIAL HANDSHAKE
51       The command protocol is defined like this:
52
53       ·      The first message send by a client to a server, when opening the
54              connection,  contains  two  words.  The  first word is a list as
55              well, and contains the versions of the wire protocol the  client
56              is willing to accept, with the most preferred version first. The
57              second word is the TCP port the client is listening on for  con‐
58              nections  to itself. The value 0 is used here to signal that the
59              client will not listen for connections, i.e. that it  is  purely
60              for sending commands, and not receiving them.
61
62       ·      The  first message sent by the server to the client, in response
63              to the message above contains only one  word.  This  word  is  a
64              list,  containing  the string vers as its first element, and the
65              version of the wire protocol the server has  selected  from  the
66              offered versions as the second.
67
68   SCRIPT/COMMAND MESSAGES
69       All messages coming after the initial handshake consist of three words.
70       These are an instruction, a transaction id, and the payload. The  valid
71       instructions  are  shown  below.  The  transaction  ids are used by the
72       client to match any incoming replies to the command messages  it  sent.
73       This  means that a server has to copy the transaction id from a command
74       message to the reply it sends for that message.
75
76       send
77
78       async
79
80       command
81              The payload is the Tcl script to execute on the  server.  It  is
82              actually  a list containing the script fragments. These fragment
83              are concatenated together by the server to form the full  script
84              to  execute  on  the  server side.  This emulates the Tcl "eval"
85              semantics.  In most cases it is best to have only  one  word  in
86              the list, a list containing the exact command.
87
88              Examples:
89
90
91
92                  (a)     {send 1 {{array get tcl_platform}}}
93                  (b)     {send 1 {array get tcl_platform}}
94                  (c)     {send 1 {array {get tcl_platform}}}
95
96                  are all valid representations of the same command. They are
97                  generated via
98
99                  (a')    send {array get tcl_platform}
100                  (b')    send array get tcl_platform
101                  (c')    send array {get tcl_platform}
102
103                  respectively
104
105
106       Note  that  (a),  generated  by (a'), is the usual form, if only single
107       commands are sent by the client.  For example constructed  using  list,
108       if the command contains variable arguments. Like
109
110
111
112                  send [list array get $the_variable]
113
114
115       These  three  instructions  all  invoke  the script on the server side.
116       Their difference is in the treatment of result values, and thus  deter‐
117       mines if a reply is expected.
118
119              send   A  reply  is  expected.  The  sender  is  waiting for the
120                     result.
121
122              async  No reply is expected, the sender has no interest  in  the
123                     result and is not waiting for any.
124
125              command
126                     A  reply  is  expected, but the sender is not waiting for
127                     it. It has arranged to get a  process-internal  notifica‐
128                     tion when the result arrives.
129
130       reply  Like  the  previous three command, however the tcl script in the
131              payload is highly restricted.  It  has  to  be  a  syntactically
132              valid  Tcl  return  command.  This  contains result code, value,
133              error code, and error info.
134
135              Examples:
136
137
138
139                  {reply 1 {return -code 0 {}}}
140                  {reply 1 {return -code 0 {osVersion 2.4.21-99-default byteOrder littleEndian machine i686 platform unix os Linux user andreask wordSize 4}}}
141
142

BUGS, IDEAS, FEEDBACK

144       This document, and the package it describes, will  undoubtedly  contain
145       bugs  and  other  problems.  Please report such in the category comm of
146       the  Tcllib  Trackers  [http://core.tcl.tk/tcllib/reportlist].   Please
147       also  report any ideas for enhancements you may have for either package
148       and/or documentation.
149
150       When proposing code changes, please provide unified diffs, i.e the out‐
151       put of diff -u.
152
153       Note  further  that  attachments  are  strongly  preferred over inlined
154       patches. Attachments can be made by going  to  the  Edit  form  of  the
155       ticket  immediately  after  its  creation, and then using the left-most
156       button in the secondary navigation bar.
157

SEE ALSO

159       comm
160

KEYWORDS

162       comm, communication, ipc, message, remote communication, remote  execu‐
163       tion, rpc, socket
164

CATEGORY

166       Programming tools
167
169       Copyright (c) 2005 Docs. Andreas Kupries <andreas_kupries@users.sourceforge.net>
170
171
172
173
174tcllib                                 3                          comm_wire(n)
Impressum