"Java sockets" is a misnomer, since sockets are not specific to Java
or any other programming language. Java provides an interface to the
socket mechanism (sometimes called "Berkeley sockets") already
provided by your operating system.

TCP is a reliable protocol. It manages retransmission when data is out
of order, missing or corrupt, and it will break the connection when it
is unable to provide an error-free data stream, but not before making
a number of attempts to correct the situation first.

Your application can safely assume that as long as your connection is
up, your data stream contains exactly the data sent by the remote.

There are however a number of things that your application can do
wrong. The commonest ones to watch out for are thinking that TCP will
respect your message boundaries (it won't), or expecting that you'll
always read as much data as you requested (you won't).

/gordon

--

That is handled by TCP/IP. Each IP datagram contains multiple checksums. There
are at least checksums for the IP header and for the TCP segment (header+data).
Other protocols layered on top of TCP/IP may add their own.

Sockets are very reliable. The Internet is built on them.

If you look at the format of a TCP/IP packet you can get an idea.
see http://mindprod.com/jgloss/tcpip.html

TPC/IP packets have a 16 bit checksum. Any single bit error would give
you a different checksum.  A multibit error has an 1 in 2^16 chance of
coming up with the valid checksum.

This is in addition to any packet-level checksums or hardware error
correction transparent to TCP/IP (e.g. error correcting modems).

The backbones now are fibre optic which very rarely get errors.  The
problems comes from the rather wretched quality of the copper near
your end.

Perhaps someone knows of a tool to get the stats on the percentage of
packets getting through. The worse that number is the worse your
throughput and the greater your odds of an error sneaking through.

In my personal case they must be very rare. Nearly all my high volume
traffic is in ZIP files which have an additional checksum.  I don't
see problems.

"But my tax return has to be correct.  I submitted it with an
error-correcting modem."

Most local area networks these days are TCP/IP using Berkley sockets. It is
extremely reliable. Java sockets simply wrap the platform specific
implementation of Berkley sockets.

TCP (Transmission Control Protocol) is responsible for reliability, error
correction and in-order delivery of the data.

IP (Internet Protocol) is responsible for hardware abstraction, data
transfer, routing, etc., but does not guarantee data integrity (except for
the IP headers, without which TCP reliability would be impossible).

For more information, see http://en.wikipedia.org/wiki/Tcp/ip

It is certainly possible to design an application that is unreliable by
using Berkley sockets inappropriately in Java (or any language or platform,
for that matter). It is also possible to design extremely reliable
applications using Berkley sockets, but it requires some understanding of
detecting and recovering from network failures (such as unplugged cables,
switching and router failures, etc.). Fortunately, Java sockets throw
IOExceptions when things like this occur.

One situation that most sockets will not tell you there is a problem is if
(for example) someone disconnects a cable on the *far side* of an Ethernet
switch that you are connecting through. There is no "heartbeat" in the
TCP/IP protocol. So your socket could listen for hours if no one reconnects
the cable. You can program sockets to time out on a read, but it is quite
common for the distant terminal to remain quiet for hours in some cases. The
TELNET protocol provides ways to periodically poll a device for connection
presence. It is more common than not for applications to layer other
protocols on top of TCP/IP to implement application-specific signaling
requirements.