socket read timeout

[Jean-Paul Calderone]

On Fri, 30 Mar 2007 08:22:18 +0200, Hendrik van Rooyen <mail at microcorp.co.za> wrote:
>"Jean-Paul Calderone" <ex...n at d...od.com> wrote:
>
>> On Thu, 29 Mar 2007 07:29:35 +0200, Hendrik van Rooyen
><m....l at m.....orp.co.za> wrote:
>
>> >Are sockets full duplex?
>>
>> Uh, yes.
>
>The reason I asked is that I have noticed that other file like objects
>(on Suse 10 Linux and Python 2.4 out of the box) aren't  really:
>
>If you start a blocking read in one thread on a serial port, and you
>then issue a write in another thread, the characters are not transmitted
>until the read completes.  It is as if the "driver" gets busy in the read
>and queues the write - I think a lot of the "My output does not come
>out till I close the programme" type of questions on this group is
>caused by this.   And calling flush makes no difference under these
>circumstances.- you have to unblock and use try - except on the read
>as well.

So posix has this great abstraction around places data can come from and go
to, file descriptors.  But actually it's not so great, because it leaks all
over the place.  Oh well.

Once you get to this level of detail (ie, "is it full duplex?"), then you
really do have to be thinking about what's behind the file descriptor.  A
serial port _can_ be full duplex, but isn't always.  Other kinds of file
descriptors might also be full duplex or they might not be.  It just depends
what the file descriptor really is.

>
>So I was wondering if sockets are the same, as I haven't messed
>with them much- just set up simple client server stuff in a
>"Monkey see, Monkey do" way.
>

Fortunately for us though, TCP sockets are full duplex. :)  Of course, maybe
"full duplex" is an over-simplification.  What does it really mean, anyway?
Does it mean that you can always read at the same time as you are writing?
What does "at the same time" mean anyway?  Oh well, I can just keep assuming
it's just a sort of vague hand-wavey feature. :)

>> >I know Ethernet isn't.
>>
>> Not that this is relevant, but unless you're using a hub, ethernet _is_
>> full duplex.
>
>: - ) Yes the UTP allows point to point full duplex, as there are separate
>receive and transmit pairs.
>
>But the protocol is not called Carrier Sense Multiple Access with
>Collision Detection for nothing. - there can be no collisions in a true
>full duplex channel. And its kind of difficult to swap rx and tx pairs
>if there are more than two endpoints - you need a central point, and then
>the "slaves" can't hear each other unless the central point passes the
>messages on, or does some switching functions.
>
>Reason I mentioned Ethernet is that in most cases (between machines)
>its the underlying technology and if sockets were therefore not actually
>full duplex it would not be surprising.
>
>Is it actually possible to do what I have described for the serial port
>case on a socket and have the message transmitted before one is
>received?  Using a blocking receive?

I'm going to keep saying yes here, but it's hard to explain why without
agreeing on a really detailed definition of "full duplex" and then most
likely also talking about a bunch of things below the TCP interface to
sockets.

Jean-Paul