Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
Miscellaneous TCP/IP Troubleshooting Protocols: Echo, Discard, Character Generator, Quote Of The Day, Active Users, Daytime, Time
The old quip says that the only guarantees
in life are death and taxes. When it comes to networking, you can add
a few more, including this one: as soon as you set up a network, it
will very quickly develop problems that you will need to address. Recognizing
that the complexity of TCP/IP internetworks would make diagnosing certain
problems difficult, the suites architects defined a number of
miscellaneous utility protocols that can be helpful in testing and troubleshooting
networks. Despite having been around for over 20 years, these protocols
are somewhat obscure and get little attention. I too will not devote
much time to them (since they are no longer implemented on many systems)
but I do feel they are worth a quick look.
These simple protocols are designed
to be implemented as services that run on TCP/IP servers. Each listens
for requests on a dedicated well-known
port number, and then responds with a
particular type of information. These protocols can be used with both
TCP and UDP, enabling each transport protocol to be tested. In the case
of UDP, the server counts each UDP sent to it as a request, and sends
a response to it. When used with TCP, a connection is of course first
established by the client to the server. In some of the protocols, this
connection is then used to send data continuously between the client
and server; in others, the establishment of the connection is considered
an implied request to the server, which will immediately send a response
and then close the connection.
Table 311
provides a brief description of each of these troubleshooting protocols/services
under both UDP and TCP. I have shown for each the port number that the
service uses, and also the RFC that defines it, if you want additional
information.
Table 311: Miscellaneous TCP/IP Troubleshooting Protocols
Protocol
|
Well-Known
Port Number
|
Defining
RFC
|
Description
|
Echo Protocol
|
7
|
862
|
Echoes received data back to
its originator. When used on UDP, the payload of each message is simply
packaged into a return UDP datagram and sent back. For TCP, each byte
sent by the client is echoed back by the server until the connection
is closed.
|
Discard
Protocol
|
9
|
863
|
Throws away
all data that is sent to it. I think this should be called the Black
Hole Protocol. J
|
Character Generator
Protocol
|
19
|
864
|
Generates random characters of
data and sends them to a device. When used with UDP, each UDP message
sent to the server causes it to send back a UDP message containing a
random number (0 to 512 bytes) of data. When used with TCP, the server
just starts sending characters as soon as a client establishes a connection,
and continues until the connection is terminated by the client.
|
Quote
of the Day Protocol
|
17
|
865
|
Sends a short
message (selected by the servers administrator) to a client device.
For UDP, the message is sent for each incoming UDP message; for TCP,
the message is sent by the server once when the connection is established,
which is then closed.
|
Active Users
|
11
|
866
|
Sends a list of active users
to a device. For UDP, the list is sent for each incoming UDP message;
if it is longer than 512 bytes it will be sent in multiple messages.
For TCP, the list is sent automatically when the connection is made
to the server, and then the connection is terminated.
|
Daytime
Protocol
|
13
|
867
|
Returns the
current time on the server in human-readable form, in response to receipt
of a UDP message or an incoming TCP connection.
|
Time Protocol
|
37
|
868
|
Returns the current time in machine-readable
formspecifically, the number of seconds since midnight, January
1, 1900 GMT. The time is sent for each UDP message received by the server,
or upon establishment of a TCP connection.
Note that this protocol cannot be used for time synchronization of servers,
because it does not compensate for variability in the time required
for the messages to be carried over the internetwork.
|
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|