470,872 Members | 1,744 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,872 developers. It's quick & easy.

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

Mar 27 '07 #1
18 3210
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 ?

--
Jarek Zgoda

"We read Knuth so you don't have to."
Mar 27 '07 #2
Jarek Zgoda wrote:
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 ?
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

Mar 27 '07 #3
>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)
JarekDid you see http://www.timo-tasi.org/python/timeoutsocket.py ?

Also socket objects have timeout attributes now.

Skip

Mar 27 '07 #4
hg
Steve Holden wrote:
Jarek Zgoda wrote:
>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 ?
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

Mar 27 '07 #5
hg wrote:
Do you mean use select ?
No, socket's timeout:
>>import socket
s = socket.socket()
s.settimeout(5)
...
Regards,

--
.. Facundo
..
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Mar 27 '07 #6
hg
Facundo Batista wrote:
hg wrote:
>Do you mean use select ?

No, socket's timeout:
>>>import socket
s = socket.socket()
s.settimeout(5)
...

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
Mar 28 '07 #7
hg wrote:
Facundo Batista wrote:
>hg wrote:
>>Do you mean use select ?
No, socket's timeout:
>>>>import socket
s = socket.socket()
s.settimeout(5)
...
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 ...
If you want selective timeout behaviour then yes, you should use select.

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

Mar 28 '07 #8

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

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

Skip
Mar 28 '07 #9
hg
sk**@pobox.com wrote:
>
hgMy issue with that is the effect on write: I only want a timeout
on
hgread ... but anyway ...

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

Skip

Not bad .. thanks

Mar 28 '07 #10
<skip@p....x.comwrote:

>
hgMy issue with that is the effect on write: I only want a timeout on
hgread ... 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
Mar 29 '07 #11
>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.
Both are full duplex.

--
damjan
Mar 29 '07 #12
Hendrik van Rooyen wrote:
<skip@p....x.comwrote:

> hgMy issue with that is the effect on write: I only want a timeout on
hgread ... but anyway ...

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

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

Apr 1 '07 #13
"Steve Holden" <s..e@hol....eb.com>

Hendrik van Rooyen wrote:
<skip@p....x.comwrote:

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

So set a long timeout when you want to write and short timeout when you
want
to read.
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.
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.
>
I know Ethernet isn't.
Don't know much, then, do you? ;-)
No not really - I easily get confused by such things as collisions...

: - )

- Hendrik

Apr 1 '07 #14
Steve Holden wrote:
Hendrik van Rooyen wrote:
>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.
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?
--
--Bryan
Apr 1 '07 #15
"Bryan Olson" <fa*********@nowhere.orgwrote:

Steve Holden wrote:
Hendrik van Rooyen wrote:
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.

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

Apr 2 '07 #16
Hendrik van Rooyen wrote:
"Steve Holden" <s..e@hol....eb.com>

>Hendrik van Rooyen wrote:
>> <skip@p....x.comwrote:
hgMy issue with that is the effect on write: I only want a timeout on
hgread ... but anyway ...

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

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.

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.
>>I know Ethernet isn't.
Don't know much, then, do you? ;-)

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

Apr 2 '07 #17
Bryan Olson wrote:
Steve Holden wrote:
>Hendrik van Rooyen wrote:
>>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.

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

Apr 2 '07 #18
"Steve Holden" <s..e@h...b.comwrote:
>
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
Apr 3 '07 #19

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Adam | last post: by
2 posts views Thread by Ted Burhan | last post: by
reply views Thread by Tomasz Naumowicz | last post: by
2 posts views Thread by Lisa Pearlson | last post: by
3 posts views Thread by Mike Schilling | last post: by
1 post views Thread by Mani | last post: by
reply views Thread by PAzevedo | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.