As per Relevance of the word connection, we have this rfc below:
Network Working Group R.
Request for Comments: 1159 Clarkson
June 1990
Message Send
Status of this
This RFC suggests an Experimental Protocol for the
community. Hosts on the Internet that choose to implement a
Send Protocol may experiment with this protocol. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
The Message Send Protocol is used to send a short message to a
user on a given terminal on a given host. This is similar to
service provided by Unix's write command, which is limited to
users on that host. This service is also known on some hosts
"SEND".
As the Internet grows, more and more people are using hosts that
not run TCP/IP at all times. These hosts may be able to use a
protocol that can be implemented in a subset of TCP/IP. The
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
a user's terminal. SMTP's SEND is not useful in this
because TCP requires quite a bit of code. For the purposes
standardization, we will include a TCP based Message Send Service
TCP Based Message Send
One message send service is defined as a connection based
on TCP. A server listens for TCP connections on TCP port 18. Once
connection is established a short message is sent by the client
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
Another message send service is defined as a datagram
application on UDP. A server listens for UDP datagrams on UDP
18. When a datagram is received by the server, an answering
Nelson [Page 1]
RFC 1159 Message Send Protocol June 1990
is sent back to the client containing exactly the same data
Message
The message should consist of several parts. The first part is
single octet indicating the protocol revision, currently decimal 65,
'A'. The second part is the name of the user that the message
directed to. This and the remaining parts are null-terminated,
consist of eight-bit characters. Do not strip the eighth bit of
characters. The third part is the name of the terminal. The
part is the actual message
The total length of the message shall be less than 512 octets.
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
console
If this protocol is changed, the revision number will be changed.
no case will any of the four parts be removed
It is advisable for servers to strip escape sequences before
them to actual terminals. Some terminals can do nasty things
you send them certain escape sequence
In both the TCP and UDP versions of the service, checksums are
used
Security
Security issues are not addressed in this memo
Author's
Russell
Educational Computing
Clarkson
Potsdam, NY 13699-5730
Phone: (315) 268-6455
EMail: nelson@sun.soe.clarkson.
Nelson [Page 2]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
