socket.sendto / UDP problem
Todd Walter
twalter at rogers.com
Fri Oct 22 08:08:57 EDT 2010
-----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.
No problem. I will keep trying until I get it! :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAkzBfuEACgkQwnknPuQqPIM0RACbBIqd8Ajf0APavZP4GkjeXSG0
DL4An07ZH+N5MVq8rru/OmsOpoR1CmnN
=QFwU
-----END PGP SIGNATURE-----
More information about the Python-list
mailing list