Professional Documents
Culture Documents
Last-modified: 1996/4/1
Internet Protocol Frequently Asked Questions
Maintained by: George V. Neville-Neil (gnn@wrs.com)
Contributions from:
Ran Atkinson
Mark Bergman
Stephane Bortzmeyer
Rodney Brown
Dr. Charles E. Campbell Jr.
Phill Conrad
Alan Cox
Rick Jones
Jon Kay
Jay Kreibrich
William Manning
Barry Margolin
Jim Muchow
Subu Rama
W. Richard Stevens
Version 3.3
************************************************************************
The following is a list of Frequently Asked Questions, and
their answers, for people interested in the Internet Protocols,
including TCP, UDP, ICMP and others. Please send all additions,
corrections, complaints and kudos to the above address. This FAQ will
be posted on or about the first of every month.
This FAQ is available for anonymous ftp from :
ftp.netcom.com:/pub/gnn/tcp-ip.faq . You may get it from my home page at
ftp://ftp.netcom.com/pub/gnn/gnn.html
You can read the FAQ in HTMl format on Netcom or from the mirror
site http://web.cnam.fr/Network/TCP-IP/tcp-ip.html
************************************************************************
Table of Contents:
Glossary
1) Are there any good books on IP?
2) Where can I find example source code for TCP/UDP/IP?
3) Are there any public domain programs to check the performance of an
IP link?
4) Where do I find RFCs?
5) How can I detect that the other end of a TCP connection has
crashed? Can I use "keepalives" for this?
6) Can the keepalive timeouts be configured?
7) Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal addresses
to an official network?
8) Are there object-oriented network programming tools?
9) What other FAQs are related to this one?
10) What newsgroups contain information on networks/protocols?
11) Van Jacobson explains TCP congestion avoidance.
12) Can I use a single bit subnet?
Glossary:
I felt this should be first given the plethora of acronyms used in the
rest of this FAQ.
IP: Internet Protocol. The lowest layer protocol defined in TCP/IP.
This is the base layer on which all other protocols mentioned herein
are built. IP is often referred to as TCP/IP as well.
UDP: User Datagram Protocol. This is a connectionless protocol built
on top of IP. It does not provide any guarantees on the ordering or
delivery of messages. This protocol is layered on top of IP.
TCP: Transmission Control Protocol. TCP is a connection oriented
protocol that guarantees that messages are delivered in the order in
which they were sent and that all messages are delivered. If a TCP
connection cannot deliver a message it closes the connection and
informs the entity that created it. This protocol is layered on top
of IP.
ICMP: Internet Control Message Protocol. ICMP is used for
diagnostics in the network. The Unix program, ping, uses ICMP
messages to detect the status of other hosts in the net. ICMP
messages can either be queries (in the case of ping) or error reports,
such as when a network is unreachable.
RFC: Request For Comment. RFCs are documents that define the
protocols used in the IP Internet. Some are only suggestions, some
are even jokes, and others are published standards. Several sites in
the Internet store RFCs and make them available for anonymous ftp.
SLIP: Serial Line IP. An implementation of IP for use over a serial
link (modem). CSLIP is an optimized (compressed) version of SLIP that
gives better throughput.
Bandwidth: The amount of data that can be pushed through a link in
unit time. Usually measured in bits or bytes per second.
Latency: The amount of time that a message spends in a network going
from point A to point B.
Jitter: The effect seen when latency is not a constant. That is, if
messages experience a different latencies between two points in a
network.
RPC: Remote Procedure Call. RPC is a method of making network access
to resource transparent to the application programmer by supplying a
"stub" routine that is called in the same way as a regular procedure
call. The stub actually performs the call across the network to
another computer.
Marshalling: The process of taking arbitrary data (characters,
integers, structures) and packing them up for transmission across a
network.
MBONE: A virtual network that is a Multicast backBONE. It is still a
research prototype, but it extends through most of the core of the
Internet (including North America, Europe, and Australia). It uses IP
Multicasting which is defined in RFC-1112. An MBONE FAQ is available
via anonymous ftp from: ftp.isi.edu" There are frequent broadcasts of
multimedia programs (audio and low bandwidth video) over the MBONE.
Though the MBONE is used for mutlicasting, the long haul parts of the
MBONE use point-to-point connections through unicast tunnels to
connect the various multicast networks worldwide.
5) How can I detect that the other end of a TCP connection has crashed?
Can I use "keepalives" for this?
A) Detecting crashed systems over TCP/IP is difficult. TCP doesn't require
any transmission over a connection if the application isn't sending
anything, and many of the media over which TCP/IP is used (e.g. ethernet)
don't provide a reliable way to determine whether a particular host is up.
If a server doesn't hear from a client, it could be because it has nothing
to say, some network between the server and client may be down, the server
or client's network interface may be disconnected, or the client may have
crashed. Network failures are often temporary (a thin ethernet will appear
down while someone is adding a link to the daisy chain, and it often takes
a few minutes for new routes to stabilize when a router goes down), and TCP
connections shouldn't be dropped as a result.
Keepalives are a feature of the sockets API that requests that an empty
packet be sent periodically over an idle connection; this should evoke an
acknowledgement from the remote system if it is still up, a reset if it has
rebooted, and a timeout if it is down. These are not normally sent until
the connection has been idle for a few hours. The purpose isn't to detect
a crash immediately, but to keep unnecessary resources from being allocated
forever.
If more rapid detection of remote failures is required, this should be
implemented in the application protocol. There is no standard mechanism
for this, but an example is requiring clients to send a "no-op" message
every minute or two. An example protocol that uses this is X Display
Manager Control Protocol (XDMCP), part of the X Window System, Version 11;
the XDM server managing a session periodically sends a Sync command to the
display server, which should evoke an application-level response, and
resets the session if it doesn't get a response (this is actually an
example of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).
6) Can the keepalive timeouts be configured?
A) This varies by operating system. There is a program that works on
many Unices (though not Linux or Solaris), called netconfig, that
allows one to do this and documents many of the variables. It is
available by anonymous FTP from
cs.ucsd.edu:pub/csl/Netconfig/netconfig2.2.tar.Z
In addition, Richard Stevens' TCP/IP Illustrated, Volume 1 includes a
good discussion of setting the most useful variables on many
platforms.