socket.sendto / UDP problem

[Todd Walter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 22 Oct 2010 10:53:45 -0400
Tom Pacheco <tomslists at netp.org> wrote:

>   On 10/21/2010 4:05 PM, Todd Walter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thu, 21 Oct 2010 17:03:58 +0100
> > MRAB<python at mrabarnett.plus.com>  wrote:
> >
> >> On 21/10/2010 15:57, Todd Walter wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> On Thu, 21 Oct 2010 00:07:58 +0100
> >>> MRAB<python at mrabarnett.plus.com>   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'sp
> >>> bound to a source port (192.168.10.2:2260, the local machine) and
> >>> just transmits to an address with a port glommed onu sn
> >>> (192.168.10.1:2002, the PLC).
> >> [snip]
> >> What I meant was that you're using 'pcSocket' for both directions
> >> and using .bind on it.
> >>
> >> Try creating two sockets, 'pcInSocket' and 'pcOutSocket', and bind
> >> only pcOutSocket.
> > As it turns out, Windows will throw a 10022 if you try and .recvfrom
> > on an unbound port so I went back to the old way as it didn't seem
> > to be related to my problem.  I re-captured the packets from the
> > utility again and I noticed that my text string is getting s p a c
> > e d o u t in the datagram whereas the primary utility sends a nice
> > cohesive "spacedout".  My early transmissions work this way,
> > successfully, as well and I think it is because either Python or
> > Windows is treating my text strings differently than my numerical
> > strings; more clearly when I send "1234" it goes out "1234" and
> > when I send "Todd" it goes out as "T o d d ".   This will obviously
> > overflow the PLC and cause a reset.
> >
> > Any ideas?
> >
> > Regards,
> >
> > - - Todd
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.16 (GNU/Linux)
> >
> > iEYEARECAAYFAkzAnQUACgkQwnknPuQqPIOx6QCgjNP/S/dODwO/c7xk8xKZk1A7
> > IMQAniGKd5yaqRo3nAmHJJsrkEP6iL/j
> > =aH+4
> > -----END PGP SIGNATURE-----
> 
> 
> what version of python are you using?
> It sounds like you might be using python 3 which uses unicode for
> strings. you would need to switch to bytes like b"Todd"
> 
>   - tom
> 
> 

Python 2.6.6.  That being said, there used to be an installation of 3.1
on the system that I removed.  Would it be possible for stale .DLLs to
interact with the 2.6.6 interpreter?

Thanks for your help,

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

iEYEARECAAYFAkzBqxoACgkQwnknPuQqPIO0SQCfcxdLqZevWEzWnwzJ8iHxNNLo
fIcAniDEHDVGEQhptrvJ/Bd2wqwVezt6
=n8Rx
-----END PGP SIGNATURE-----