Twisted and connected UDP example

[Joakim Bech]

At this page
--> http://twistedmatrix.com/documents/current/howto/udp
is an example that shows how connected UDP is done
with Twisted. I can't get it to work.
When I run it, it says:

....
self.startProtocol()
File "./client2.py", line 10, in startProtocol
d.addCallback(self._cbConnected)
AttributeError: 'NoneType' object has no attribute 'addCallback'
....

I.e it looks like the
"d = self.transport.connect("ip_to_listening_server", listen_port_nbr)"
doesn't return anything?

As server at "the other side" I've used the first example
and I have also tried using netcat as an listening UDP-server.
I'm sure that the IP-adress and port is correct in my code,
so it can't be that.

(Btw, the self.transport.write .. line is not correct indented
I suppose?)

Anyone that can help me with this?

[David Bolen]

Joakim Bech <jy*@telia.com> writes:

At this page
--> http://twistedmatrix.com/documents/current/howto/udp
is an example that shows how connected UDP is done
with Twisted. I can't get it to work.
When I run it, it says:

...
self.startProtocol()
File "./client2.py", line 10, in startProtocol
d.addCallback(self._cbConnected)
AttributeError: 'NoneType' object has no attribute 'addCallback'
...

I.e it looks like the
"d = self.transport.connect("ip_to_listening_server", listen_port_nbr)"
doesn't return anything?

Right - it looks like the example is out of date. The connect()
method on the UDP transport did previously return a deferred because
it depended on an underlying socket connect, but was later revised
(looks like in March, 2004 from the svn logs) at which point it was no
longer a deferrable operation. I'm guessing the example wasn't
updated to match (you may want to file a defect on the twisted site
against it).

The UDP stuff in Twisted has remained labeled unstable for as long as
I've been working with Twisted. This particular connect() method is
fairly recent (it wasn't in Twisted 1.1.0 for example), although there
was an alternate connected UDP transport or something in earlier releases.

I'd suggest just taking out the callback - as currently implemented,
the call to connect() will complete synchronously and will have
established the target address as the target for subsequent
communication.

-- David