1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Network Working Group Bob Bressler
Request for Comments: 441 Bob Thomas
NIC 13773 January 19, 1973
<span class="h1">Inter-Entity Communication - An Experiment</span>
This note is an attempt to be a status report concerning an
experiment based on the desire of users, at their consoles, to
converse with one another, and perhaps to get some debugging
assistance. The user might ask: "who can I talk to"; "can I show him
what I have done", and "can I let him run my program?" Many time
sharing systems provide capabilities such as these, within the bounds
of their system. Almost all systems have a "WHO" or "SYSTAT", many
have commands like "LINK" or "TALK", and some support more esoteric
capabilities like controlling another user's program. At the last
formal meeting of the Network Working Group, in October of 1971 at
MIT, a group got together to talk about these features for Inter
Entity Communications (IEC), and how they might be extended to span
across Host boundaries.
Subsequent development has proceeded in an ad hoc manner. The
general design philosophy paralleled that of TELNET in terms of
having both server and user programs. The server program would
handle commands like "connect to user FOO", "where is user BAR", or
"who is on your system?" An initial implementation of a server and
user was brought up at MIT-DMCG, using a completely arbitrary
protocol. Soon after that, in an effort to increase its usefulness,
the protocol was modified to be compatible with that being used by
the Resource Sharing Executive being developed at BBN-TENEX.
The MIT user program used the concept of "ports" to help identify
character streams entering and leaving an object. A pictorial
diagram follows (FIGURE 1) showing a user teletype, his job and two
consultants with whom he is conversing.
<span class="grey">Bressler & Thomas [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc441">RFC 441</a> Inter-Entity Communication January 1973</span>
+------+
| USER |
| TTY |
+------+
| |
-------------|---|--------------+
| | | +-------+
+------------------+ | | HOST |
| COMMAND | | | A |
| INTERPRETER | | +-------+
+---+-+-------+-+--+ | |
TTY |_| |_| TTY | |
OUT-PORT ^ | IN-PORT | |
| | | |
| V | +--------------+ |
+-|-+ | |
<----| |IN-PORT |--+
+-|-+ |
| | CONSULTANT |
| | #1 |
+-|-+ |
I.E.C. ---->| |OUT-PORT |
+-|-+ |
| +--------------+
|
| +--------------+
+-|-+ |
<----| |IN-PORT |--+
+-|-+ | |
| | CONSULTANT | |
| | #2 | |
+-|-+ | |
^ | ---->| |OUT-PORT | |
| | +-|-+ | |
JOB | V JOB | +--------------+ |
IN-PORT+--+ +--+OUT-PORT | |
-----|--|-------|--|----------+ |
+----+ +-------+ +---------+ |
| | +------+
| USER JOB | | HOST |
| B |
+------+
The user now has the option of opening or closing any of the ports he
wishes. While in conversation mode, he might turn off the ports
leading to the JOB. If he wished consultant 1 to control the job, he
might turn off the input ports from his own TTY and from consultant
2.
<span class="grey">Bressler & Thomas [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc441">RFC 441</a> Inter-Entity Communication January 1973</span>
Towards this goal, the user interface provides the following set of
commands:
WHO user supplies which host, and given a list of [user,
teletype, jobs].
WHERE user supplies identification of another user, and program
tries to find him on all the servers it knows about (for
1 server, that code was very easy to write!)
OPEN or CLOSE user specifies which port to turn on or turn off.
PORT MAP gives the user a picture of all his ports.
CONNECT user specifies host, user, and port identification. If
successful, results in an open connection to the
specified user.
DISCONNECT user specifies port, and connection is cleanly broken.
The above description applies to the program at MIT-DMCG. Similar
ones will soon be available on the other ITS systems.
From TENEX, the user interface is through the RSEXEC subsystem. To
the user, the RSEXEC looks much like the standard TENEX EXEC, but not
limited to just the local system. With the exception of the concept
of PORTS, the command structure is similar to that previously
described:
@ WHERE (is user) THOMAS
Lists each "currently active" job of user Thomas. Each job
is identified by its network site, job I.D. and attached
terminals.
@ SITES (of user) BRESSLER
Lists all of the (currently accessible) network sites where
user Bressler has an account.
@ LINK (to TTY0 103 (AT SITE) UTAH-10
Links the user's terminal to terminal 106 at the UTAH PDP-
10.
@ WHO Lists the users currently logged in at each (accessible)
network site. (WHO has options for specifying selected
sites.)
<span class="grey">Bressler & Thomas [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc441">RFC 441</a> Inter-Entity Communication January 1973</span>
Supplementing the above services, the TENEX RSEXEC program provides a
set of files system tools. It is planned to integrate these services
with the FTP type protocols, and make these services available on
other non-TENEX systems.
Socket 245 (decimal) has been assigned to this experiment. As
mentioned above, these services are now (or will soon be) available
on many ITS and TENEX systems. In addition, at least one of these
services will be available on a non login basis. This will enable TIP
users to avail themselves of these communication facilities.
Further participation in this experiment is of course invited. It is
hoped that a service like this can play an important role in network
development. Sites are invited to experiment with the "conferencing"
possibilities of this experiment. We would be interested in knowing
what drawbacks are encountered. The protocol design will remain
flexible, and can be expanded to meet short comings that use will
discover. Areas of experimentation include integration with the mail
protocol, conference scheduling, and incorporating a picture oriented
graphics protocol, for graphics users to share screens.
Attached is a copy of the protocol currently used. At first glance,
it may appear hostile to non PDP-10s, but this was not intentional.
A new and more general protocol is being developed, but since this
one is operational, it seems useful to try using it.
INTERIM PROTOCOL
There are two parts to the RSEXEC protocol:
1. an initial connection protocol which specifies how a user program
connects to the server program, and
2. a command protocol which specifies how the user process talks to
the server process to get service.
Initial Connection Protocol
To connect to the server the user process connects to socket number
365 (octal) connection byte size = 32. The server program then
transmits two bytes and breaks the connection:
byte 1 = socket number = X
byte 2 = transaction number (meaningful to server)
<span class="grey">Bressler & Thomas [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc441">RFC 441</a> Inter-Entity Communication January 1973</span>
The server and user programs complete the ICP by opening two 36 bit
"working" connections:
U + 3 --> X
U + 2 --> X + 1
where U = the socket used by the user program to initiate the ICP.
After the two working connections are established the server is ready
to accept commands.
Note that the RSEXEC ICP is virtually identical to the official
ARPANET ICP, the single difference being transmission of the
transaction number.
Command Protocol
[Note on terminology:
ASCII 7 bit characters, packed 5 to a 36 bit word, with the low
order bit 0. In all following examples the contents of a
string are delimited with "/".
ASCIZ ASCII, terminated with a character (7 bits) of zero.
SIXBIT 6 bit characters, packed 6 to a 36 bit word. A sixbit
character + 60 (octal) = the equivalent ASCII character.
byte unless otherwise stated is 36 bits.
XWD A,B Half words. 18 high order bits = A, 18 low order bits =
B.]
USINF
To obtain information about a user at the server's site
1. user sends:
byte 1: ASCII /USINF/
byte 2->k: ASCIZ /USERNAME/
<span class="grey">Bressler & Thomas [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc441">RFC 441</a> Inter-Entity Communication January 1973</span>
2. server responds:
neg ack: 1 byte = XWD 0, error # ;no such user
pos ack: byte 1: -1
byte 2->n: XWD job #, tty #
where tty # = -1 if job detached
byte n+1: -1
SSTAT
To obtain the active users at the server's site
1. user sends:
byte 1: ASCII /SSTAT/
2. server responds:
neg ack: 1 byte = 0
pos ack: 1 byte = -1
followed by data blocks of the form
a. 1 byte = -1 ;means end of transmission
or
b. byte 1: XWD job #,tty #
byte 2: SIXBIT /subsys name/
byte 3->n: ASCIZ /USERNAME/
LINK
To link to a user terminal at the server site
1. user sends:
byte 1: ASCII /LINK/
byte 2: terminal #
2. server responds:
neg ack: 1 byte = 0
pos ack: 1 byte = number N ;means server will attempt link
3. if positive acknowledgement server and user try to establish the two
8 bit connections:
N + 1 --> U
<span class="grey">Bressler & Thomas [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc441">RFC 441</a> Inter-Entity Communication January 1973</span>
N --> U + 1
where U is the socket used by the user to initiate the ICP.
These connections are to be used to carry text to and from the linked
tty at the server's site.
4. server responds (a second time):
neg ack: 1 byte = 0 ;means can't establish connections or
;couldn't make the link
pos ack: 1 byte = -1 ;means link to tty established and
;anything transmitted over the
;connections will go to linked tty.
BREAK
To break a link previously established to a terminal at the server
site:
1. user sends:
byte 1: ASCII /BREAK/
2. server responds:
neg ack: 1 byte = XWD 0,error #
pos ack: 1 byte = -1 ;link successfully broken
TERMINATE
To terminate connection with the server the user can either send a
single byte = 0 or just close the connections. The former is
preferred. The server responds by breaking the connections.
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Hlne Morin, Viagnie, 12/99]
Bressler & Thomas [Page 7]
</pre>
|
