socket read timeout

[hg]

Hi,

I am looking for the most efficient / cleanest way to implement a socket
read with timeout (Windows mainly but would be great if the same code
worked under *nix)

Tanks,

hg

 

[Jarek Zgoda]

hg napisa³(a):

I am looking for the most efficient / cleanest way to implement a socket
read with timeout (Windows mainly but would be great if the same code
worked under *nix)

Did you see http://www.timo-tasi.org/python/timeoutsocket.py ?

 

[Steve Holden]

hg napisa³(a):


Did you see http://www.timo-tasi.org/python/timeoutsocket.py ?

Note that since 2.4, I believe, sockets in the standard library allow
you to specify a timeout parameter.

regards
Steve

 

[hg]

Note that since 2.4, I believe, sockets in the standard library allow
you to specify a timeout parameter.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

Hi and thanks to all.

Do you mean use select ?

Thanks,

hg

 

[skip]

Jarek> Did you see http://www.timo-tasi.org/python/timeoutsocket.py ?

Also socket objects have timeout attributes now.

Skip

 

[hg]

No, socket's timeout:


Regards,

--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

My issue with that is the effect on write: I only want a timeout on read ...
but anyway ...

Thanks,

hg

 

[Facundo Batista]

Do you mean use select ?

No, socket's timeout:

Regards,

 

[hg]

hg> My issue with that is the effect on write: I only want a timeout
on
hg> read ... but anyway ...

So set a long timeout when you want to write and short timeout when you
want to read.

Skip

Not bad .. thanks

 

[Steve Holden]

My issue with that is the effect on write: I only want a timeout on read ...
but anyway ...

If you want selective timeout behaviour then yes, you should use select.

regards
Steve

 

[skip]

hg> My issue with that is the effect on write: I only want a timeout on
hg> read ... but anyway ...

So set a long timeout when you want to write and short timeout when you want
to read.

Skip

 

[Hendrik van Rooyen]

hg> My issue with that is the effect on write: I only want a timeout on
hg> read ... but anyway ...

So set a long timeout when you want to write and short timeout when you want
to read.

Are sockets full duplex?

I know Ethernet isn't.

- Hendrik

 

[Damjan]

So set a long timeout when you want to write and short timeout when you

Are sockets full duplex?

I know Ethernet isn't.

Both are full duplex.

 

[Steve Holden]

Are sockets full duplex?

Yes. But you have to use non-blocking calls in your application to use
them as full-duplex in your code.

I know Ethernet isn't.

Don't know much, then, do you? ;-)

regards
Steve

 

[Hendrik van Rooyen]

Yes. But you have to use non-blocking calls in your application to use
them as full-duplex in your code.

This seems to bear out the scenario I have described elsewhere in this
thread - I think its caused by the file handlers, but I don't _know_ it.

Don't know much, then, do you? ;-)

No not really - I easily get confused by such things as collisions...

: - )

- Hendrik

 

[Bryan Olson]

Yes. But you have to use non-blocking calls in your application to use
them as full-duplex in your code.

Hmmm... I'm missing something. Suppose I have one thread (or
process) reading from a blocking-mode socket while another is
writing to it? What stops it from being full duplex?

 

[Hendrik van Rooyen]

Hmmm... I'm missing something. Suppose I have one thread (or
process) reading from a blocking-mode socket while another is
writing to it? What stops it from being full duplex?

Elsewhere in this thread I wrote about my experience with a serial port,
where I can show that the "file handler" only does the write once the
blocking read completes - and the point at issue is if sockets are the same.

We regularly get questions about "my stuff does not come out" on
the group, and I wondered whether this effect is the underlying cause.

But I don't know about the sockets case, which is why I asked.

You raise an interesting point about a different process - my serial
experience is using threads. I have never tried mixing processes
on a serial port. Haven't a clue if its possible, or if the behaviour
will be different.

- Hendrik

 

[Steve Holden]

This seems to bear out the scenario I have described elsewhere in this
thread - I think its caused by the file handlers, but I don't _know_ it.


No not really - I easily get confused by such things as collisions...

: - )

Right, but collisions are *so* twentieth-century, aren't they. With a
properly-implemented switched infrastructure Ethernet interfaces can
transmit and receive at the same time.

regards
Steve

 

[Steve Holden]

Hmmm... I'm missing something. Suppose I have one thread (or
process) reading from a blocking-mode socket while another is
writing to it? What stops it from being full duplex?

Nothing, I guess. I just didn't consider threaded code ...

regards
Steve

 

[Hendrik van Rooyen]

Right, but collisions are *so* twentieth-century, aren't they. With a
properly-implemented switched infrastructure Ethernet interfaces can
transmit and receive at the same time.

This is true, while "A" and "B" are not simultaneously trying to address
"C" - Then you need something like store and forward, on the fly...

: - ) better known as "routing"...

Some (most?) of the little switches I have seen are too dumb even to
allow "A" to talk to "B" while "C" is talking to "D" - they just broadcast
the first "talker"'s message to all the "listeners" - little better than
active hubs, destroying the end point's hardware capability to talk and
listen at the same time.

I think the keywords here are "properly implemented" - its actually not a
trivial problem, as the switch has to know or learn who is where, and set
up paths accordingly, in real time. This is hard to do without store and
forward.

- Hendrik