At 06:35 PM 4/13/00 +0530, Akshay Adhikari wrote:
>Hi,
>
>In what sense are TCP sockets full duplex? Sure, data can flow in each
>direction independent of the other direction, but it wont work if this
>happens at the same time.
>
>THat is, if a client and server process simultaneously send (thats
>full-duplex) one window's worth of data on their connection, theyll
>deadlock, each waiting for the other to acknowledge receipt, which is not
>going to happen.
>
>So the programming has to be symmetric right? One sends, other receives -
>that makes it half duplex. Could anyone shed some light on this?
The TCP/IP protocols use windowing, with separate windows in each
direction. The protocol is more than capable of handling traffic in both
directions simultaneously, because each logical channel is time-division
multiplexed between data and supervisory functions. So if both sides send
data at exactly the same time, and the media has separate channels for each
direction, the packets cross in the media, get received in each system, and
the TCP/IP protocol performs the proper action for receipt of packets by
generating the proper response, perhaps piggy-backed on the data.
If you have data moving in both directions at the same time, each packet
contains both supervisory information and data. The time specifications
encourage such packet-sharing, so that protocols such as TELNET when
character is enabled consume about half the bandwidth that it would if such
packet-sharing was not encouraged.
With certain media, such as Ethernet, the send and receive "channels" are
time-division multiplexed on the media, and in fact for most LANs the
multiplexing is not only by "direction" but also by peer-peer pairs. In
short, the "duplexness" is full-duplex to the media driver, with the media
driver and hardware taking care of the details.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
