TCP/IP : Java Glossary

* 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (all)

TCP/IP

TCP/IP (Transmission Control Protocol/Internet Protocol). The protocol that Internet uses to transfer packets in continuous byte streams. It allows interleaving many streams of information on the same connection. It can also be used as a LAN (Local Area Network) protocol. Other special-purpose Internet protocols, such as HTTP (Hypertext Transfer Protocol) and FTP (File Transfer Protocol), are piggybacked on top of TCP/IP. Stream-level TCP/IP in turn is piggybacked on top of IP (Internet Protocol) packet-level protocol. It allows a two-way error free continuous binary stream to be transmitted.

menu
How It Works	Performance
Port Assignments	TCP/IP vs UDP
Timeouts	Books
Disconnet Detection	Links

How It Works

TCP/IP sits atop the IP packet protocol. First understand how that works. TCP (Transmission Control Protocol) has its own packet header that looks like this:

TCP Segment Header for Client to Server Packet
Field	Size in bits	Purpose
total length	16	Not in the TCP header, but rather in the basic IP header. It is the total size of the IP header, TCP segment header plus the data payload measured in 8-bit chunks (aka bytes or octets). The means the maximum size of a packet including data is 64K. This means the payload of data is at most 65,495 bytes.
source IP	32	Not in the TCP header, but rather in the basic IP header. Who sent the packet. When it finally arrives at its destination the receiver will know who it was from.
destination IP	32	Not in the TCP header, but rather in the basic IP header. Where the packet is going. On each leg of its journey the routing computer uses this to get the packet a little closer to its final destination.
source port	16	A free port on the client’s machine where the server should send all responses. There will be a different port for every new session, even to the same port on the server. So in theory a caller could have up to 65535 sessions going at once on just one of the server’s ports. From the point of view of the server, the source port is effectively a session number.
destination port	16	Which program on the server this should be directed to. All clients in the world will be sending to this same port for this program. The program sorts out the sessions by looking at the source-IP and source-port.
sequence number	32	The offset in the continuous stream where data in this packet belongs. Think of it as the offset in a virtual file at the receiver’s end where to plop this chunk.
acknowledgement number	32	The offset in the continuous stream up to which data has been received successfully. A few packets may have been received successfully past an unreceived hole, but they don’t count. This lets the other end know what has been received successfully so far.
hlen	4	size of packet header measured in 32-bit chunks.
window	16	0 means, I am not prepared to receive any more packets for a while. N means I have sufficient buffers so that I am prepared to receive data in the stream up to offset acknowledgement number + n. I don’t know what the units of measure are. If bytes, that means the sliding window can be only 64K.
checksum	16	This is computed as the 16-bit one’s complement of the one’s complement sum of a pseudo header of information from the IP header, the TCP header and the data, padded as needed with zero bytes at the end to make a multiple of two bytes.
other stuff	28	Miscellaneous fields.

Everything is in big endian byte order.

The sender and receiver send data packets to each other. TCP/IP is a moving window protocol like the old Kermit protocol of BBS (Bulletin Board System) days, but with a variable size window. The receiver ACKs the offset where in the byte stream it has so for received successfully. It never sends NAKs. For flow control, each end avoids being overwhelmed with window advertising, i.e. telling the sender how much free buffer space it still has for receiving packets. When it wants to stop the flow it says 0 space. When it wants to start the flow again it advertises a non-zero value.

It is a symmetrical peer to peer protocol. Either client or server could initiate the connection and both uses identical protocols to send, receive, handle flow control, disconnect etc. It is an elegant protocol, about as simple as a protocol could be, yet with plenty of room for intelligent optimisation within the framework.

How does TCP/IP keep track of many users coming in on the same port, much less the same user opening many sessions on the same port? In each TCP packet header are four numbers:

TCP/IP Segment Header
Field	Size	Where
source IP	32 bits	IP header
source port	16 bits	TCP header
destination IP	32 bits	IP header
destination port	16 bits	TCP header

Any packet coming in can be identified with whom it is from (source IP), port they want to talk to (destination port) and which session on that port this packet is pertinent to (source port). The source port has to be unique to the source IP, but that same number might be reused on another connection with a different source IP.

Wireshark, formerly known as Ethereal, is a utility to let you snoop on TCP/IP traffic in and out of your machine.

Port Assignments

There are some ports reserved for particular use, such as port 80 for HTTP. These are called well known ports. IANA reserves port numbers in the range 1 to 1023 for well known ports. Other times the port number does not matter. You can pick one out of a hat, so long as it is not already in use. These are called ephemeral ports. When you call into a server, typically your destination port is well known and your source port is ephemeral and the server’s destination port is ephemeral and its source port is well known. IANA (Internet Assigned Numbers Authority) maintains a database of port assignments. There is no mechanism similar to Plug N Play to assign ports. You have to pick a default port and allow the end user to configure a different one if it clashes, as if the average user today had the tiniest clue how to go about that. The low 16000s are usually a safe bet. If you run multiple copies of the same server, you will need to configure them to use different ports.

Firewalls control traffic and an out of your LAN by examining the source and destination ports in each TCP/IP segment header going through and also the source and destination IP s.

In Windows you can find out who is using which ports this way:

REM find out who is using which TCP/IP sockets
netstat -o

rem you might get a result like this:
rem Proto  Local Address          Foreign Address        State           PID
rem TCP    192.168.0.101:49181    209.34.241.67:http     ESTABLISHED     4908

Rem you can then get more information about what that PID means
TaskList /o

Also try SysInternals TCPView for a more details look at what is going on your machine with TCP/IP and UDP (User Datagram Protocol).

Timeouts

TCP/IP uses an adaptive scheme to figure out how long it should wait for ACKs before giving up and retransmitting a packet. It dynamically monitors the history of how fast the ACKs come to determine the optimal wait time.

As an application programmer, you may be concerned with other timeouts:

How long to wait without any ACKs? If there are no ACKs, the connection has probably been lost.
How long should you wait for the receiver to stay blocked (not reading the data and refusing to accept any more)? If there are no ACKs, the receiving application may have failed.
How long should the socket connection be allowed to be idle? Somebody using the program went home without shutting it down.

Java offers Socket.setSoTimeout to control how long you are willing to wait while the receiver blocks and Socket.setSoLinger to control how long it lingers, (waits to close when there are still unsent data). setSoTimeout has no effect on how long you are willing to wait for a read (how long you are willing to wait for the other end to produce data), just on how long you are willing for your write to complete (how long you are willing for the other end to keep advertising 0 buffer space for more incoming packets).

Disconnect Detection

Since TCP/IP sends no packets except when there is traffic, without Socket.setKeepAlive( true ), it has no way of noticing a disconnect until you start trying to send (or to a certain extent receive) traffic again. Java has the Socket.setKeepAlive( true ) method to ask TCP/IP to handle heartbeat probing without any data packets or application programming. Unfortunately, you can’t tell it how frequently to send the heartbeat probes. If the other end does not respond in time, you will get a socket exception on your pending read. Heartbeat packets in both directions let the other end know you are still there. A heartbeat packet is just an ordinary TCP/IP ACK packet without any piggybacking data.

When the applications are idling, your applications could periodically send tiny heartbeat messages to each other. The receiver could just ignore them. However, they force the TCP/IP protocol to check if the other end is still alive. These are not part of the TCP/IP protocol. You would have to build them into your application protocols. They act as are-you-still-alive? messages. I have found Java’s connection continuity testing to be less that 100% reliable. My bullet-proof technique to detect disconnect is to have the server send an application-level heartbeat packet if it has not sent some packet in the last 30 seconds. It has to send some message every 30 seconds, not necessarily a dummy heartbeat packet. The heartbeat packets thus only appear when the server is idling. Otherwise normal traffic acts as the heartbeat. The Applet detects the lack of traffic on disconnect and automatically restarts the connection. The downside is your applications have to be aware of these heartbeats and they have to fit into whatever other protocol you are using, unlike relying on TCP/IP level heartbeats.

However, it is simpler to use the built-in Socket.setKeepAlive( true ) method to ask TCP/IP to handle the heartbeat probing without any data packets or application programming. Each end with nothing to say just periodically sends an empty data packet with its current sequence, acknowledgement and window numbers.

The advantage of application level heartbeats is they let you know the applications at both ends are alive, not just the communications software.

You can tell which TCP/IP sessions your machine has active by typing: netstat -an.

Performance

Using a simple tool like TCP Optimizer or TweakMaster to tune your TCP/IP connection can make an incredible difference in speed, sometimes a 100× improvement.

By analogy, TCP/IP is like a bucket brigade to put out a fire, where a Datagram is like a bucket brigade with only one bucket. TCP/IP delivers packets in a pipeline. TCP/IP does not wait for a packet to be delivered before sending the next. UDP usually sends only one packet at a time.

What is important for performance with TCP/IP doing a long file download is how many bytes per second come through the spigot. If would not matter if each individual packet took 60 seconds to wend its way through the packet net. Thus the number of hops is not critical. What is critical is the bottleneck hop. (which varies since packets don’t take the precise same route). The response time of the server is not critical either, so long as it can keep the pipeline filled. Speeding up hops other than the bottleneck hop won’t help matters. The bottleneck will usually be the last hop to the client’s router or the first hop from the server’s router. The performance of TCP/IP as like a freeway limited by the most constricted spot where there is an accident or narrow bridge. The speed of cars through that constriction determines how many cars per hours can pass.

In contrast, for a Datagram, what counts is the round trip time for one packet to make it to the server and for a response to be formulated and a packet send back. Thus every hop is critical and the number of hops are critical.

If you were using TCP/IP to deliver sporadic packets over a socket, you are effectively using it like a Datagram. In that case, as with datagrams, every hop is critical.

If you were using Datagrams in a streaming video protocol where you had a pipeline of packets, you are effectively using the net like a non-error-correcting TCP/IP. In that case, as in TCP/IP, only the bottleneck hop is critical.

Both TCP/IP and Datagrams underneath both use the IP protocol to deliver individual packets. TCP/IP just adds a formal layer stream, keeping many packets in flow at once and arranging for redelivery of failed packets.

TCP/IP vs UDP

You use UDP instead of TCP/IP when:

It is not crucial if a packet is lost.
If retransmitted, a failed packet would be pointless. It if does not arrive in real time, you can’t hold up the works to get a correct copy, e.g. in Internet radio or streaming video.
You want to send or receive small amounts at a time, ideally that would fit into a single packet.
You want to sporadically send/receive to/from a wide variety of stations. You avoid the overhead of a setting up and maintaining a socket to each one.
For NTP (Network Time Protocol), where it is important to get packets as quickly as possible and know precisely when they arrived.
You need ultimate speed. You are willing to forego the general convenience of TCP/IP.

You use TCP/IP instead of UDP when:

You want to transport large volumes of data.
Accuracy is important.
You want to use HTTP which piggybacks over TCP/IP.

If you have poor quality lines, you will get scrambled or lost packets that have to be retransmitted, slowing down the flow. To estimate the quality of your lines see ping.

Books

recommend book⇒Internetworking with TCP/IP Vol.1: Principles, Protocols and Architecture, fourth edition

Douglas E. Comer

978-0-13-470188-2

paperback

publisher

Prentice Hall

978-0-13-018380-4

hardcover

published

2000-01-18

How IP, UDP and TCP/IP protocols work. How the domain name to IP translation DNS information in propagated.

Online bookstores carrying Internetworking with TCP/IP Vol.1: Principles, Protocols and Architecture, fourth edition
	abe books anz	abe books.ca
	abe books.de	amazon.ca
	amazon.de	Chapters Indigo
	amazon.es	Chapters Indigo eBooks
	iberlibro.com	abe books.com
	abe books.fr	amazon.com
	amazon.fr	Barnes & Noble
	abe books.it	Nook at Barnes & Noble
	amazon.it	Kobo
	junglee.com	Google play
	abe books.co.uk	O’Reilly Safari
	amazon.co.uk	Powells
	other stores

Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

standard footer
	This page is posted on the web at:	http://mindprod.com/jgloss/tcpip.html
	Optional Replicator mirror of mindprod.com on local hard disk J:	J:\mindprod\jgloss\tcpip.html
	Please read the feedback from other visitors, or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission.
	Canadian Mind Products IP:[65.110.21.43] Your face IP:[3.17.175.191]
Feedback	You are visitor number