Re: pyzor report timeouts

[Tony M. <to...@sp...>]

Hi,

The problem is definitely resolved now.  If you want to know the
technical details of what happened, read on.  If not, you're done!

The server that public.pyzor.org was moved to has multiple IP
addresses.  public.pyzor.org was pointed to one setup as eth0:1, but
the pyzord client was bound to all interfaces.  The pyzor client would
correct send a message to pyzor, and pyzord would send a message back
to the client.  However, the response would have the eth0 IP address
as the sender (because pyzord can't tell which IP was connected to,
and so all outgoing messages are from the 'default' interface).  The
client then silently rejected this response, because it didn't match
the sendto IP (this occurs at the C library level, not in the pyzor or
Python code).  It seems that this is just how UDP works on many
servers.

As far as I have been able to determine, the only way to solve this is
to either connect to the default interface (which is the case now) or
to bind only to the IP that is wanted (we might swap to that, but
no-one will notice anything if we do).

I still don't understand why this didn't happen universally.  I wonder
if it has something to do with the implementation of the underlying C
library, although I could both reproduce the problem and have it work
in the same OS.

More of the gory details are available here, if anyone is
super-interested:
http://stackoverflow.com/questions/1309370/does-a-udp-service-have-to-respond-from-the-connected-ip-address

Apologies again for the downtime.

Thanks,
Tony