socket.sendto / UDP problem

Todd Walter twalter at
Thu Oct 21 16:57:45 CEST 2010

Hash: SHA1

On Thu, 21 Oct 2010 00:07:58 +0100
MRAB <python at> wrote:

> >
> [snip]
> The docs for 'sendto' say:
>      """The socket should not be connected to a remote socket, since
> the destination socket is specified by address."""
> Could your problem be caused by you binding the socket to a source
> port, so it's going out both to the bound port _and_ the one given the
> binding?
> Have you tried using two sockets, one outgoing and the other incoming?
> BTW, your code for handling the response doesn't cope with it coming
> in a bit at a time. It loops discard any previous data from the
> previous iteration.
> Also, it's more Pythonic to say:
>      while '\r' not in response:
>          ...
I haven't bound the socket to a remote port, as I read it; it's bound to
a source port (, the local machine) and just transmits
to an address with a port glommed on (, the PLC). 
Unfortunately I cannot alter the PLC's logic; it was provided by the
vendor without source (and I'm not entirely sure i have the appropriate
software to deal with it anyway as we're an Omron/A-B shop).  I based
this code on the actual conversation on the wire from the utility GUI
that came with the storage unit. It ping pongs back and forth on just
those two ports, likely because the old controller used a RS232
half-duplex interface. That being said, I don't know for a fact that the
PLC cares about the source port -- they are usually pretty "dumb" and
only care about the input but you never know what's been hard-coded.  I
will have to test this.  

I am primarily interested in the '\r'; it serves as the EOT (ie.,
'over' not 'out')  I know the response packet size is fixed and it only
gets sent once in full.  No re-transmission or fragmentation (this is
likely by design - full stack isn't really necessary on this kind of

I'll change my loops to be more pythonic; it reads better.

Thanks for your help,

- - Todd
Version: GnuPG v2.0.16 (GNU/Linux)


More information about the Python-list mailing list