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
|
Xtell Protocol
This document briefly describes protocol used by xtell program.
Motivation:
There is a lack of program providing way of sending casual
messages between remote computers.
There exists well established unix utility write(1), which serves
its purpose well, but its major drawback is that it is limited to a
single host. Xtell tries to provide write-like facility for
communicating between remote computers.
Terminology:
"Client" is program sending the message to remote computer
"Server" is a daemon receiving the message and delivering
it to specified user.
Protocol:
xtell server listens on TCP port (default 4224).
Upon received connection, it reads lines separated by CRLF.
Client indicates the end of connection by
special command QUIT (case insensitive) sent as the last line of communication,
terminated by CRLF, after which server should close the connection.
After each read line (except QUIT), server sends the response back to the
client. For response codes, see below.
Each line is a separate message, which has the form:
FROM:USER:DEVICE:MESSAGE
FROM is the identity of user sending the message. The exact form
is implementation dependent, but suggested form is the login name
of user sending the message, if remote OS provides the information.
Server could do further inquiries about the real identity of
sender, to reduce the possible fake identities, for example by
using IDENT protocol.
Name of computer the connection is coming from is usually deduced from
incoming TCP connection.
FROM can be left empty if the client OS does not provide the information;
however, server is not guaranteed to deliver messages with empty FROM.
USER is the identity of user the message is intended for.
If the local OS is single-user, dealing with this information is
left to the implementation of xtell server (example implementation
could ignore the USER parameter and display the message if OS does
not have a "logged in user" notion, or check it and deliver the message only
if logged in user matches USER parameter).
USER can be left empty, if the notion of logged in user is meaningless
on server OS.
DEVICE further specifies the message delivery, in case of more
possibilities. For server running on UNIX, typical usage of DEVICE
is the name of tty the message should be delivered to in case of
multiple times logged user.
DEVICE can be left empty (and usually it is), in which case server
should try to find "best possible device" to deliver the message to -
usually the terminal with minimal idle time.
(the alternative, to deliver message to all the devices user is
logged into, is also possible and actually used in VMS implementation)
FROM, USER and DEVICE must not contain colons.
MESSAGE is the text of the message delivered to user. No other limitations
on the message are imposed, however, it is strongly recommended that the message
is sent as 7-bit ASCII or superset of ASCII. For communication where use of
text encoding other than ASCII is convenient, it is suggested that the
encoding is UTF-8.
Although the length of MESSAGE is not limited, typical xtell implementation
could impose further limits. Typically, xtell is intended for short messages,
up to a few lines of text (several hundreds of bytes)
RESPONSE CODES:
Response form simple line, terminated with CRLF.
Response has form:
NNN response_text
where NNN is a 3-digit numerical code, and response text has an informative
character and in case of error replies intended for the user.
Numerical code can start either with digit '2' in case of successfully
sent message, or with digit '4' in case of failure.
Second 2 digits can be used to specify more precisely the type of response.
For example, responses can look like this:
200 - message sent
403 - user is not currently logged in
404 - user has indicated that s/he does not want to receive messages
(mesg n)
405 - there was an error writing to specified device - either
user has disabled sending messages to the device client specifies,
or, if client does not explicitly specify a device, the message
could not have been delivered.
406 - syntax error, format of line was not recognised
|
