Message Send Protocol
A lightweight way to flash short messages between computers on the Internet.
Nelson, R., "Message Send Protocol", RFC 1159, DOI 10.17487/RFC1159, June 1990, <https://www.rfc-editor.org/info/rfc1159>.
@misc{rfc1159,
series = {Request for Comments},
number = 1159,
howpublished = {RFC 1159},
publisher = {RFC Editor},
doi = {10.17487/RFC1159},
url = {https://www.rfc-editor.org/info/rfc1159},
author = {R. Nelson},
title = {{Message Send Protocol}},
pagetotal = 2,
year = 1990,
month = jun,
} RFC text
Contents
Network Working Group R. Nelson
Request for Comments: 1159 Clarkson University
June 1990
Message Send Protocol
Status of this Memo
This RFC suggests an Experimental Protocol for the Internet
community. Hosts on the Internet that choose to implement a Message
Send Protocol may experiment with this protocol. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
Discussion
The Message Send Protocol is used to send a short message to a given
user on a given terminal on a given host. This is similar to the
service provided by Unix's write command, which is limited to the
users on that host. This service is also known on some hosts as
"SEND".
As the Internet grows, more and more people are using hosts that do
not run TCP/IP at all times. These hosts may be able to use a simple
protocol that can be implemented in a subset of TCP/IP. The Message
Send Protocol is one such protocol.
Note that a message sending protocol is already defined using TCP.
The SMTP protocol includes a "SEND" command that will direct mail to
a user's terminal. SMTP's SEND is not useful in this instance
because TCP requires quite a bit of code. For the purposes of
standardization, we will include a TCP based Message Send Service.
TCP Based Message Send Service
One message send service is defined as a connection based application
on TCP. A server listens for TCP connections on TCP port 18. Once a
connection is established a short message is sent by the client out
the connection (and any data received by the client is thrown away).
The client closes the connection after sending the message.
UDP Based Message Send Service
Another message send service is defined as a datagram based
application on UDP. A server listens for UDP datagrams on UDP port
18. When a datagram is received by the server, an answering datagram
is sent back to the client containing exactly the same data.
Message Syntax
The message should consist of several parts. The first part is a
single octet indicating the protocol revision, currently decimal 65,
'A'. The second part is the name of the user that the message is
directed to. This and the remaining parts are null-terminated, and
consist of eight-bit characters. Do not strip the eighth bit of the
characters. The third part is the name of the terminal. The fourth
part is the actual message.
The total length of the message shall be less than 512 octets. This
includes all four parts, and any terminating nulls.
If the terminal part is empty, then "the right" terminal is chosen.
If the user part is empty, then the message is written on the
console.
If this protocol is changed, the revision number will be changed. In
no case will any of the four parts be removed.
Advisories
It is advisable for servers to strip escape sequences before sending
them to actual terminals. Some terminals can do nasty things when
you send them certain escape sequence.
In both the TCP and UDP versions of the service, checksums are always
used.
Security Considerations
Security issues are not addressed in this memo.
Author's Address
Russell Nelson
Educational Computing System
Clarkson University
Potsdam, NY 13699-5730
Phone: (315) 268-6455
EMail: nelson@sun.soe.clarkson.edu
AI ELI5
On this page
§1The Problem and Solution
The Message Send Protocol (RFC 1159) solves a specific problem: some hosts run TCP/IP only part of the time, and for those hosts, the full overhead of a connection-based protocol is impractical for a simple task like flashing a short message to a user's screen. The protocol provides a lightweight alternative to deliver a short message to a specific user on a specific terminal on a given host, similar to the Unix write command but across the network.
When a computer cannot run full network protocols all the time, it still wants to send quick notes to users on other computers.
§2Two Service Options
The RFC defines two versions of the service. The TCP-based version uses TCP port 18: a client connects, sends the message, and the server sends the same data back (which the client ignores), then closes the connection. The UDP-based version uses UDP port 18 as well: the client sends a datagram, and the server echoes it back. Both approaches carry the same message format.
The message structure has four null-terminated parts: a single-octet protocol version (decimal 65, the ASCII character 'A'), the target user name, the terminal name (or empty to pick the right one automatically), and the message text itself. The entire message must be under 512 octets.
You can send a message either through a fast connection (TCP) or a quick packet (UDP). Both ways put your message in four parts: the version, who to send to, which screen, and what to say.
§3Security and Implementation Notes
The RFC advises implementations to strip escape sequences before delivering messages to actual terminals, to prevent hostile input from causing problems. Checksums are always used in both TCP and UDP versions. The RFC explicitly notes that security issues are not addressed in the memo.
Servers should be careful about strange characters in messages so they do not break the terminal, and the protocol includes safety checks.