socket.sendto / UDP problem

[MRAB]

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.