TCP/IP : Java Glossary


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.
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     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).


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:

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.


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.


You use UDP instead of TCP/IP when:

You use TCP/IP instead of UDP when: 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.


book cover recommend book⇒Internetworking with TCP/IP Vol.1: Principles, Protocols and Architecture, fourth editionto book home
by 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.
Australian flag abe books anz abe Canadian flag
German flag abe Canadian flag
German flag Chapters Indigo Canadian flag
Spanish flag Chapters Indigo eBooks Canadian flag
Spanish flag abe American flag
French flag abe American flag
French flag Barnes & Noble American flag
Italian flag abe Nook at Barnes & Noble American flag
Italian flag Kobo American flag
India flag Google play American flag
UK flag abe O’Reilly Safari American flag
UK flag Powells American flag
UN flag other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number