socket.sendto / UDP problem

[Todd Walter]

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

On Fri, 22 Oct 2010 00:00:03 +0100
MRAB <python at mrabarnett.plus.com> wrote:

> On 21/10/2010 21:05, 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.
>  >
> Oops! I should've said "bind only pcInSocket". Sorry! :-(
>                                                                         |
>  > 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?
>  >
> If they're all bytestrings then the contents shouldn't matter. Try
> printing their repr just to check.

Printing the repr() results in the exact string I built.  I infer this
to mean that the cause is lower down; either in the socket module or
the Windows stack.  XP SP2 was known to do buggy things with UDP
sockets; I wonder if that is what is causing me grief.  I'm going to
extract this part of the code and try it on my Linux laptop and see if
I can get different results.

Thanks for your help,

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

iEYEARECAAYFAkzBhKcACgkQwnknPuQqPIOf6wCfe8xouwHBJGnC2eHbKo+Eyvjo
tw4AnjbSd9gnoAigJsDfowQQ1vM+rkFv
=/GQV
-----END PGP SIGNATURE-----