Akshay Adhikari wrote:
> > > 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.
> >
> > Sure it will.
>
> What I should have said was - I have one client and one server, both send
> MORE that a windows worth of data .
The window size isn't relevant here; it's the size of the buffers that
counts..
> Both do
>
> for (i = 0 to 1000)
> send ();
>
> and then for (i = 0 to 1000)
> recv ()
>
> I sent 1000 packets of size 1400 bytes, and both programs crashed after abt
> 50 - 60 sends.
Nothing should crash. All that should happen is that the sender blocks
once it can't send any more data.
> Thats the whole point of flow control, isnt it - neither process has dequed
> received data (by issuing a recv), and so window size gradually goes to 0,
> both processes wait for the other to open up its window which it wont do
> because it hasnt done a recv () yet - that'l happen only after the 1000
> sends are over. Ofcourse, if you use non-blocking sockets, the problem could
> be avoided.....
Yes. But as I pointed out, this isn't a TCP issue. If you want to
implement a full duplex protocol, each end has to be able to send and
receive concurrently. Which is probably why Internet protocols are
generally half duplex.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
