This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Datagram Socket Timeouts
Type: Stage:
Components: Documentation Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: nnorwitz, tvrankar
Priority: normal Keywords:

Created on 2005-09-29 14:05 by tvrankar, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
PythonUDPSocketBug.zip tvrankar, 2005-09-29 14:05 demo scripts (subject stuff happens in the client)
Messages (5)
msg26456 - (view) Author: Tom Vrankar (tvrankar) Date: 2005-09-29 14:05
Python 2.4.1, MS Windows 2000 with service packs

I'm trying to have a UDP client check for its server to
start by repeatedly throwing messages at where it's
expected to appear, and then checking for a response. I
set a timeout on the recvfrom, expecting to block for
the timeout and then proceeding to an exception
handler, looping so until data is returned. Instead,
the recvfrom throws an immediate exception "Connection
reset by peer", and I loop rapidly without the
load-softening effect of the timeout (in fact, it's the
same behavior as if I didn't set the timeout at all).
What UDP "connection" is it talking about?

Seems wrong, but is it the implementation or is it me?
If I start the server first, I get one "Invalid
argument" exception in the client. In both cases, once
the server is started, both processes are satisfied.

Thanks.

twv
msg26457 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-09-30 05:30
Logged In: YES 
user_id=33168

Can you program the client in C and see if it behaves the
same?  Sockets are mostly just wrappers around the OS calls.
 It's possible this is the expected behaviour on Windows and
python is just exposing that to you.

I ran this on Linux and got this (which is what I think you
want):

neal@janus clean $ ./python PyBug/client.py &
[1] 31484
neal@janus clean $ timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
./python PyBug/server.py
timed out
timed out

timed out
('127.0.0.1', 40899) says CHECK
('127.0.0.1', 3000) says OK
[10587 refs]
[10585 refs]
[1]+  Done                    ./python PyBug/client.py
msg26458 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-09-30 05:43
Logged In: YES 
user_id=33168

This is a dupe of 1307357, but I'm closing that one since
most of the comments are here.  However, note this one
comment from twv in the other report that says it also works
on Solaris 8 and could well be Windoze specific.
msg26459 - (view) Author: Tom Vrankar (tvrankar) Date: 2005-09-30 17:50
Logged In: YES 
user_id=1353485

With Python around, I don't program much in C anymore, and
for the same reason I usually assume platform independence
(ensured by some clever Python programmer -- C or lib --
spackling over minor underlying differences) unless the
Python docs explicitly tell me otherwise. nnorwitz's Linux
results match my Solaris 8 results (and are what I
intended). I submitted this report since the docs didn't
provide any warnings about Python's UDP sockets behaving
differently per platform. The behavior I saw would be wacky
even on Windoze, but I don't know just how tolerant Windoze
developers are of a poor sockets implementation :-).
msg26460 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-10-03 00:44
Logged In: YES 
user_id=33168

I added a note near the top of the socket module doc. 

"""Some behavior may be platform dependent, since calls are
made to the operating system socket APIs."""

Let me know if you think something more needs to be done.

Checked in as:
 * Doc/lib/libsocket.tex 1.90, 1.88.2.2
History
Date User Action Args
2022-04-11 14:56:13adminsetgithub: 42431
2005-09-29 14:05:52tvrankarcreate