TCP/IP Programming Manual

Flow control can be achieved through:
• Rate-based
• Sliding window
• Explicit pacing
• Over subscription (guarantees that the sender cannot overrun the receiver’s capacity. The
receiver’s capacity is greatly in excess of the sender’s capacity).
A common misconception states that UDP is more efficient than TCP. However, that idea is only
true when you do not need flow control, data and session-loss detection, and accounting for
receiving out-of-sequence data. If you do need these properties, you have to provide them
programmatically.
However, all flow control must account for the possibility that a datagram could be lost by the
network due to congestion or other causes.
UDP is a datagram protocol and TCP is a stream-oriented protocol. TCP is also called
connection-oriented while UDP is called connectionless.
TCP guarantees all the properties not supplied by datagram protocols:
• Loss of data detection (delivery assurance)
• Receiving data out of sequence
• Flow control
• Session loss detection
• Congestion avoidance
If these properties are implemented by a higher-level protocol that rides over UDP, you can use
UDP. Or, if these properties are not important (as is often the case with broadcast messages) you
can use UDP.
Optimal Ways to Deal With Connection Management
Since Guardian does not use signals (like OSS), for Guardian socket programs, the loss of
connection may be detected, but is not reportable until the next socket operation so issuing any
call might result in an immediate error. So it is possible that on issuing any of the calls, you may
get an immediate return indicating an error.
For both OSS and Guardian sockets, if you have lost a connection, send operations may not have
made it to the other side before the loss of connection. Therefore, if your application needs to
ensure data reception by the other side, you must have a higher-level protocol that has some form
of feedback from the other side reflecting positive receipt of the data or the ability to reestablish
a synchronization point after the detection of loss of connection. Such a protocol would need, at
minimum, sequencing on the data and the ability, when the connection is reestablished, for the
receiving side to tell the sending side that it received data up to a specific point or to start over
again at a specific point. That process is the reestablishment of synchronization. The higher-level
protocol must reestablish synchronization because even TCP does not.
For example, if you are trying to send records of a files to the other side and you send records 1
through 1,000, you could get send completions for everything up to 1,000. But that only means
that your TCP/IP stack buffered everything, not that it successfully sent everything. In fact, an error
might occur, including loss of connection, after the data has been buffered. So, records 997 through
1,000 would still be sitting in the buffer and you would have no way to know that they never were
sent. A higher-level protocol would have numbered the records, then when the loss of connection
occurred, it would re-contact the other side and ask which records were sent.
FTP is an example of a higher-level protocol, but it does not do all of these functions. FTP makes
you start over from the beginning. FTP establishes synchronization at the end of file. When receiving
data, it looks for the start of the file, then everything in between, and then the end of the file. If a
Multicasting Operations 47