socket read timeout

[Hendrik van Rooyen]

"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 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.

> >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?

- Hendrik