Mahmood Hikmet added the comment:
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
Christian Heimes added the comment:
Thanks for your response! I'm closing the ticket.
--
nosy: +christian.heimes
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11631
Martin v. Löwis added the comment:
I still can't reproduce it. I'm attaching client and server scripts that
communicate over 127.0.0.1. This works just fine.
--
Added file: http://bugs.python.org/file26914/server.py
___
Python tracker
Changes by Martin v. Löwis mar...@v.loewis.de:
Added file: http://bugs.python.org/file26915/client.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11631
___
Mahmood Hikmet added the comment:
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,
Antoine Pitrou added the comment:
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
Mahmood Hikmet added the comment:
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
New submission from Kristoffer Nilsson novaf...@gmail.com:
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
Santoso Wijaya santoso.wij...@gmail.com added the comment:
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:
Kristoffer Nilsson novaf...@gmail.com added the comment:
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
Santoso Wijaya santoso.wij...@gmail.com added the comment:
I can't reproduce this. I'm also running 64-bit Python on 64-bit Windows 7 and
socket operations are fine for me.
--
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
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).
12 matches
Mail list logo