Java Glossary : TCP/IP

Java definitions: 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

You are here : home : Java Glossary : T words : 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 protocol. Other special-purpose Internet protocols, such as HTTP and FTP, are piggybacked on top of TCP/IP. Stream-level TCP/IP in turn is piggybacked on top of IP packet-level protocol. It allows a two-way error free continuous binary stream to be transmitted.

How It Works

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

TCP Segment Header
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.
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. See details.

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

Tdimon and Ethereal are utilities 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 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.

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 and also the source and destination IPs.

Timeouts

TCP/IP uses a 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).

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.

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.

Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture, 4th edition

0-13-018380-6

Douglas E. Comer

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

datagram ¤ DHCP ¤ ephemeral ports sniffer ¤ Ethereal ¤ IP ¤ IPv6 ¤ services ¤ UDP

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 5043.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/tcpip.html	J:\mindprod\jgloss\tcpip.html