Are Java Socket Streams safe?

Question

I'm using java Sockets and ServerSockets to connect multiple devices. Are there any risks that part of the data sent by a Socket's OutputStream just dosen't arrive at the other side's InputStream?

Answer 1

I assume that you are asking about regular sockets; e.g. TCP/IP streams.

Generally speaking, TCP will detect lost and corrupted packets and cause them to be retransmitted. It will also deal with packets that are delivered out of order. Assuming these mechanisms work, then every byte written to the output stream can be read from the corresponding input stream. However, it doesn't always work:

1. If there is prolonged disruption on the network, then there is a risk that one end of the connection could timeout the other end and break the connection before all data is received.

2. TCP uses 16-bit packet-level checksums to guard against data getting corrupted in practice. There is a small probability that a random packet corruption won't be detected by the checksumming. The net result would be that the wrong data arrives.

3. There are ways that a third party could interfere with an established TCP/IP connection (e.g. by injecting packets with spoofed source addresses). This could break the connection prematurely, or worse.

If you are asking about DatagramSockets, then (for example) any UDP / IP datagram could be lost. There are no guarantees that any data sent will be received.

Answer 2

Transmission Control Protocol (TCP) runs on top of IP, and provides a connection-oriented service between the sender and the receiver. TCP provides guaranteed delivery and ensures that the packets are delivered in sequence. The underlying network IP is highly unreliable and does not provide any guarantee for TCP. In order to provide reliability between the sender and the receiver, TCP uses various mechanisms, such as sequence numbers, acknowledgments, 3-way handshakes and timers.

By doing this, the sender and receiver can verify whether the data was delivered correctly. They can also determine whether data was dropped, possibly because of loss in transit.

Both the sender and the receiver exchange initial sequence numbers (ISN) during the connection setup phase. After a successful initial handshake, both the sender and the receiver know the sequence numbers that they have to use for communication. Since TCP allows for delayed segments, it must accept segments that are out of sequence, but within certain bounds, known as the receiver window size. The receiver window size is also exchanged during the initial handshake. TCP will discard all segments that do not have a sequence number within the computed bounds.

Sequence Number The TCP sequence number is a 32-bit counter. In order to distinguish between different connections between the same sender and receiver, it is important that the sequence numbers do not start at 0 or any other fixed number each time a connection is opened. Hence, it is important that the first byte of data from the sender to the receiver is using a random sequence number. Current implementations increment the sequence number by a finite amount every second.

Three Way Handshake TCP uses the 3-way-handshake to set up a successful connection. When host A wants to open a connection to host B, A sends an initial segment to B. This initial segment has the Initial Sequence Number (ISN) that B needs to use to send data to A. This initial segment is identified by the SYN bit set to 1 in the TCP header. If the SYN bit is set, the 32-bit sequence number in the header is interpreted as the ISN. In all other cases (when the SYN bit is not set), the 32-bit sequence number identifies the sequence number of the first data byte contained in that segment. B on receiving the SYN from A, has to respond with another SYN, as well acknowledge the SYN sent by A. This is indicated by SYN+ACK in the state machine diagram.

Timers

Timers are closely knit with the TCP states.

Connection Establishment Timer This timer is associated with the opening of a connection. It is started when the SYN is sent during the initial connection setup. In most TCP implementations, the value of this timer is set to 75 seconds. If a time-out occurs, the connection is aborted.

FIN_WAIT timer
A FIN_WAIT_2 timer is started when there is a transition from the FIN_WAIT_1 state to the FIN_WAIT_2 state. The value of this timer is 10 minutes. A TCP segment with a FIN bit set is expected in the FIN_WAIT_2 state. If a packet with a FIN bit set is received, the timer is cancelled. On expiration of the timer, it is restarted with a value of 75 seconds. The connection is dropped if no packet with the FIN bit arrives within this period.

TIME_WAIT timer
A Time-wait timer is started when the connection enters the TIME-WAIT state. This is to allow all the segments in transit to be removed from the network. The value of the timer is usually set to 2 minutes. On expiration of the timer, the connection is terminated.

KEEP_ALIVE timer TCP usually does not send anything over the connection if there is no data to send. There is no way of distinguishing this silence from the case when the connection is broken. A keep-alive timer can be set which allows TCP to periodically check whether the other end of the connection is still active. The default value of this timer is 2 hours. After the expiration of the timer, probes are sent to the remote end. The connection is dropped if the remote does not respond to the probes.

For more details refer to this link

Answer 3

Nothing is guaranteed. If there's a network failing, your data will never get there. Barring a network failure, if you are using TCP and you are using your socket streams in a thread-safe manner and you are sure you have flushed the data from the socket's OutputStream, then it is guaranteed your data will show up. UDP, on the other hand, has no such guarantees.