Sending and Receiving Messages - TCP/IP Sockets in Java Practical Guide for Programmers - page 43

I/O Class Function

Buffered[Input/Output]Stream Performs buffering for I/O optimization.

Checked[Input/Output]Stream Maintains a checksum on data.

Data[Input/Output]Stream Handles read/write for primitive data types.

Digest[Input/Output]Stream Maintains a digest on data.

GZIP[Input/Output]Stream De/compresses a byte stream in GZIP format.

Object[Input/Output]Stream Handles read/write objects and primitive data types.

PushbackInputStream Allows a byte or bytes to be “unread.”

PrintOutputStream Prints string representation of data type.

ZIP[Input/Output]Stream De/compresses a byte stream in ZIP format.

Table 3.1: Java I/O Classes

the stream, and of the fields within the message. Whether information is encoded as text, as
multibyte binary numbers, or as some combination of the two, the application protocol must
enable the receiver of a message to determine when it has received all of the message and to
parse it into fields.
If the fields in a message all have fixed sizes and the message is made up of a fixed
number of fields, then the size of the message is known in advance and the receiver can
simply read the expected number of bytes into a byte[ ] buffer. This technique was used in
TCPEchoClient.java , where we knew the number of bytes to expect from the server. However,
when some field (and/or the whole message) can vary in length, as with the itemDescription in
our example, we do not know beforehand how many bytes to read.
Marking the end of the message is easy in the special case of the last message to be
sent on a TCP connection: the sender simply closes the sending side of the connection (using
shutdownOutput() or close() ) after sending the message. After the receiver reads the last byte
of the message, it receives an end-of-stream indication (i.e., read() returns

1), and thus can
tell that it has as much of the message as there will ever be. The same principle applies to the
last field in a message sent as a DatagramPacket .
In all other cases, the message itself must contain additional framing information en-
abling the receiver to parse the field/message. This information typically takes one of the
following forms:

−

Delimiter : The end of the variable-length field or message is indicated by a unique marker ,
an explicit byte sequence that immediately follows, but does not occur in, the data.

Explicit length : The variable-length field or message is preceded by a (fixed-size) length
field that tells how many bytes it contains.

The delimiter-based approach is often used with variable-length text: A particular char-
acter or sequence of characters is defined to mark the end of the field. If the entire message
consists of text, it is straightforward to read in characters using an instance of Reader (which