Odd UDP problems in socket library

[bluej774]

BPO	1741898
Nosy	@josiahcarlson

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2007-06-23.15:10:25.000>
created_at = <Date 2007-06-22.22:30:10.000>
labels = ['library']
title = 'Odd UDP problems in socket library'
updated_at = <Date 2007-06-23.15:10:25.000>
user = 'https://bugs.python.org/bluej774'

bugs.python.org fields:

activity = <Date 2007-06-23.15:10:25.000>
actor = 'josiahcarlson'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2007-06-22.22:30:10.000>
creator = 'bluej774'
dependencies = []
files = []
hgrepos = []
issue_num = 1741898
keywords = []
message_count = 2.0
messages = ['32382', '32383']
nosy_count = 2.0
nosy_names = ['josiahcarlson', 'bluej774']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1741898'
versions = ['Python 2.5']

[bluej774]

I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM. I was trying to use python as an SNTP client. I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py). They each exhibited a strange problem where the first info received is not what is expected. This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info. Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf

I've discovered a workaround for this bug. It only works in Python 2.5. In earlier versions, it causes the script to hang. If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info.

I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang.

for i in range(2):
	client.sendto(data, (sys.argv[1], 123))
	data, address = client.recvfrom(1024)

Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP.

Thanks for looking into it.

[josiahcarlson]

Could you produce a small runnable sample, describe what it should produce, and what it actually produces? That would make it much easier for us to help you. Thank you.