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.

Title: Python 2.7.1 64bit, Win7 64bit problem to read and write with UDP.
Type: Stage:
Components: IDLE, Windows Versions: Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Kristoffer.Nilsson, christian.heimes, loewis, pitrou, sadmoody, santoso.wijaya
Priority: normal Keywords:

Created on 2011-03-22 09:30 by Kristoffer.Nilsson, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit sadmoody, 2012-08-19 23:45 Script which should reproduce the recvfrom bug loewis, 2012-08-20 06:59 loewis, 2012-08-20 07:00
Messages (11)
msg131731 - (view) Author: Kristoffer Nilsson (Kristoffer.Nilsson) Date: 2011-03-22 09:30
Running Windows 7 Enterprise 64 bit, and Python 7.2.1 64 bit Python failed to read and send UDP packages when ran in cmd.exe. This is not the case when ran with IDLE.

Example; two simple programs. First one listening to a UDP port

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('', 10015))

reading data from socket and printing the received data, using;
data, addr = sock.recvfrom(1024)

this will lock, if not ran from IDLE.

Same for sending data, using;

sock.sendto(DATA_MESSAGE, (HOST, 10015))

this will work with both, but only send when running from IDLE.
msg131760 - (view) Author: Santoso Wijaya (santoso.wijaya) * Date: 2011-03-22 18:16
> this will lock

I should expect so! recvfrom is a blocking method. The interpreter will block on said socket until (if recvfrom) data arrives from the remote end of the socket.

sendto is non-blocking, though. And it works for me:

Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> sock.sendto('data', ('localhost', 1005))
msg131762 - (view) Author: Kristoffer Nilsson (Kristoffer.Nilsson) Date: 2011-03-22 18:33
Ah, bad formulation by me. While testing I had both the same machine and external machine sending UDP packages to the port I was listening to.

The listening server would not receive anything on 64/64bit (unless running from IDLE).

The reverse try, running the listening server (same program) on another computer, it would receive only from its own stream (while the 64/64 would only send packages while running from IDLE).

This was verified running Wireshark on both machines.

So in short, the 64/64 running from cmd.exe would not send or receive on UDP, while running from IDLE this was not the case.
msg131767 - (view) Author: Santoso Wijaya (santoso.wijaya) * Date: 2011-03-22 19:01
I can't reproduce this. I'm also running 64-bit Python on 64-bit Windows 7 and socket operations are fine for me.
msg131774 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-22 20:17
Kristoffer: are you using a personal firewall software? These filters often filter traffic out depending on what process is receiving it, so you may want to turn the firewall off (or explicitly configure it to allow this port to be open).
msg168603 - (view) Author: Mahmood Hikmet (sadmoody) Date: 2012-08-19 22:53
I am facing this same issue.

I set recvfrom to have a timeout of 5 seconds and stuck it in an infinite loop with some response code based on what is received.

The sending functionality of the socket is not compromised at all. It can always send. However, after about 10-20 minutes of normal operation (i.e. packets are being sent and received properly) - python stops being able to receive packets (but is still able to send them).

Cross-checking this with wireshark showed me that incoming packets are being received by the system (so the problem is somewhere between receiving them on the network adapter and accessing it in python).

I'm running 64bit Windows 7 with 2 network adapters (wired and wireless).

I also tried running the same python script in 4-200 processes simultaneously (but on different ports), and the error happens at the same time for ALL windows.

All firewalls are disabled.
msg168605 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-19 23:23
> I set recvfrom to have a timeout of 5 seconds and stuck it in an
> infinite loop with some response code based on what is received.

Does it make a difference if you set specify a timeout?
Could you upload a script that reproduces the issue?
Also, which Python version have you been running?
msg168606 - (view) Author: Mahmood Hikmet (sadmoody) Date: 2012-08-19 23:45
I'm unsure what you mean by "set specify" a timeout, but I do use the "settimeout()" function.

I've stripped my program of everything that is not dealing with the socket and replaced the string being sent back with a dummy one. But this is essentially how it's laid out.

I'm using Python 2.7.2
msg168627 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-08-20 06:59
I still can't reproduce it. I'm attaching client and server scripts that communicate over This works just fine.
msg175008 - (view) Author: Mahmood Hikmet (sadmoody) Date: 2012-11-06 20:18
I solved the problem - sorry it's taken me so long to reply. I know how frustrating it is when people don't respond with what they found out in the end.

Turns out there's no bug as you said and it was based around something I did (as these things usually are). I was passing the packet as a string through redis before sending it which caused it to modify some bytes in there after they passed a certain value. I pickled the messages and it all worked in the end.

Sorry about the trouble and thanks for the help!
msg175014 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-06 22:03
Thanks for your response! I'm closing the ticket.
Date User Action Args
2022-04-11 14:57:15adminsetgithub: 55840
2012-11-06 22:03:19christian.heimessetstatus: open -> closed

nosy: + christian.heimes
messages: + msg175014

resolution: not a bug
2012-11-06 20:18:48sadmoodysetmessages: + msg175008
2012-08-20 07:00:18loewissetfiles: +
2012-08-20 06:59:45loewissetfiles: +

messages: + msg168627
2012-08-19 23:45:59sadmoodysetfiles: +

messages: + msg168606
2012-08-19 23:23:27pitrousetnosy: + pitrou
messages: + msg168605
2012-08-19 22:53:24sadmoodysetnosy: + sadmoody
messages: + msg168603
2011-03-22 20:17:53loewissetnosy: + loewis
messages: + msg131774
2011-03-22 19:01:30santoso.wijayasetnosy: santoso.wijaya, Kristoffer.Nilsson
messages: + msg131767
2011-03-22 18:33:58Kristoffer.Nilssonsetnosy: santoso.wijaya, Kristoffer.Nilsson
messages: + msg131762
2011-03-22 18:16:51santoso.wijayasetnosy: + santoso.wijaya
messages: + msg131760
2011-03-22 09:30:38Kristoffer.Nilssoncreate