Re: [Twisted-Python] How to listen on and connect from same TCP port with Twisted?

[Alessio Pace]

On Sat, Jan 10, 2009 at 10:24 AM, Alessio Pace wrote:

>
>
> On Fri, Jan 9, 2009 at 3:29 PM, Jean-Paul Calderone wrote:
>
>> On Fri, 9 Jan 2009 15:13:10 +0100, Alessio Pace 
>> wrote:
>>
>>> On Fri, Jan 9, 2009 at 3:01 PM, Alvin Delagon 
>>> wrote:
>>>
>>>  You shouldn't bind your client on a port where your server is listening
 to.

>>>
>>> I'm following what is written in "Peer-to-Peer Communication Across
>>> Network
>>> Address Translators" in order to implement TCP hole punching, and they
>>> suggested to do so..
>>>
>>
>> Are you talking about section 4.2?  If so, try creating the client before
>> you create the server.  This is a somewhat arbitrary limitation imposed by
>> your platform's implementation of the BSD socket API.
>
>
> Thanks for the suggestion, I'll try this and let you know.
>

Well, apparently at least on my Linux box, I still have the same address
already bound error even if I first do connect() and then listen() using the
Twisted reactor APIs  (connectTcp(), listenTcp() ).

Any clue?
--
Alessio Pace.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] How to listen on and connect from same TCP port with Twisted?

[Jean-Paul Calderone]

On Mon, 12 Jan 2009 10:23:00 +0100, Alessio Pace  wrote:

On Sat, Jan 10, 2009 at 10:24 AM, Alessio Pace wrote:




On Fri, Jan 9, 2009 at 3:29 PM, Jean-Paul Calderone wrote:


On Fri, 9 Jan 2009 15:13:10 +0100, Alessio Pace 
wrote:


On Fri, Jan 9, 2009 at 3:01 PM, Alvin Delagon 
wrote:

 You shouldn't bind your client on a port where your server is listening

to.



I'm following what is written in "Peer-to-Peer Communication Across
Network
Address Translators" in order to implement TCP hole punching, and they
suggested to do so..



Are you talking about section 4.2?  If so, try creating the client before
you create the server.  This is a somewhat arbitrary limitation imposed by
your platform's implementation of the BSD socket API.



Thanks for the suggestion, I'll try this and let you know.



Well, apparently at least on my Linux box, I still have the same address
already bound error even if I first do connect() and then listen() using the
Twisted reactor APIs  (connectTcp(), listenTcp() ).

Any clue?


You might have to create and connect the socket before giving it to Twisted
then.

Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Manhole and StandardIO

[Zoran Bosnjak]

Hello all,
I would like to have a simple console python interactive shell,
powered by twisted.

I am looking for something like this...
---
from twisted.internet import reactor, stdio
from twisted.conch.manhole import Manhole

stdio.StandardIO(Manhole())
reactor.run()
---
... but it does not work.

Please advice.

Thanks,
Zoran
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Manhole and StandardIO

[Jean-Paul Calderone]

On Mon, 12 Jan 2009 23:09:40 +0100, Zoran Bosnjak 
 wrote:

Hello all,
I would like to have a simple console python interactive shell,
powered by twisted.

I am looking for something like this...
---
from twisted.internet import reactor, stdio
from twisted.conch.manhole import Manhole

stdio.StandardIO(Manhole())
reactor.run()
---
... but it does not work.



StandardIO accepts an IProtocol provider as an argument.  Manhole does not
implement IProtocol, it implements ITerminalProtocol.  So you cannot use
these two classes together like this.

See twisted/conch/stdio.py for examples of how to use manhole on stdio.

Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Manhole and StandardIO

[glyph]

On 10:21 pm, exar...@divmod.com wrote:
On Mon, 12 Jan 2009 23:09:40 +0100, Zoran Bosnjak 
 wrote:

Hello all,
I would like to have a simple console python interactive shell,
powered by twisted.



See twisted/conch/stdio.py for examples of how to use manhole on stdio.


It doesn't sound like you need to write any code.  Just run the module 
exarkun mentions:


   python -m twisted/conch/stdio

and you should get an interactive shell.

(If you are using GNOME, you may have to use the workaround mentioned on 
ticket 2637: .)


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Manhole and StandardIO

[Jean-Paul Calderone]

On Mon, 12 Jan 2009 22:53:29 -, gl...@divmod.com wrote:


On 10:21 pm, exar...@divmod.com wrote:
On Mon, 12 Jan 2009 23:09:40 +0100, Zoran Bosnjak 
 wrote:

Hello all,
I would like to have a simple console python interactive shell,
powered by twisted.



See twisted/conch/stdio.py for examples of how to use manhole on stdio.


It doesn't sound like you need to write any code.  Just run the module 
exarkun mentions:


   python -m twisted/conch/stdio

and you should get an interactive shell.

(If you are using GNOME, you may have to use the workaround mentioned on 
ticket 2637: .)




I think you mixed up #2637 with a different bug (which has been fixed).

Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Tracebacks being dropped from exceptions when using inlineCallbacks

[Terry Jones]

I think I've finally gotten to the bottom of why exceptions sometimes lose
their tracebacks when using inlineCallbacks.

I've spent many hours trying to track down problems that result from
this. I find the code handling failures, deferreds, and inlineCallbacks
non-trivial even in isolation, let alone when those things start
interacting. There are a lot of things that are subtle and some that I
still haven't gotten to the bottom of. The following ignores some of these
subtleties in the interest of showing how things can go wrong for the
innocent user of inlineCallbacks. I'm happy to go into detail later.

First, consider this:

import sys
from twisted.internet import defer
from twisted.python import failure

d = defer.Deferred()
try:
1 / 0
except Exception:
info = sys.exc_info()
f = failure.Failure(*info)
print "f.tb is %r" % f.tb
d.errback(f)
print "f.tb is %r" % f.tb


Which prints:

f.tb is 
f.tb is None
Unhandled error in Deferred:

That's the heart of the issue. We make a failure object, it has a
traceback, but after passing it to the errback method on a deferred the
traceback is gone.

This happens because _runCallbacks in defer.py finds no call/errback
functions to call on the deferred, drops into this code:

if isinstance(self.result, failure.Failure):
self.result.cleanFailure()

which sets the __dict__ on the failure object to the result of the
failure's __getstate__ method, which sets the traceback to None:

# added 2003-06-23. See comment above in __init__
c['tb'] = None

But the comment in __init__ seems to have been deleted.

So in summary, passing the failure to errback() results in its traceback
disappearing.


(Note that, as mentioned, there are subtleties here. E.g., try calling
failure() with no args. The above is just a very simple example.)


So what does this have to do with inlineCallbacks?

Briefly: when you decorate a function F1 with inlineCallbacks, a new
function F2 is created. When you call F2, you get back a deferred. But
before you get that deferred, F2 calls F1. F1 returns a generator G (it
yields, right?). F2 passes that generator G to _inlineCallbacks.
_inlineCallbacks initially starts G by calling its send (passing None). If
G raises an exception (other than StopIteration or returning a final value
via _DefGen_Return), _inlineCallbacks catches it via:

except:
deferred.errback()
return deferred

I.e., it calls the errback on the deferred that F2 is about to hand back to
your original code (which called the inlineCallbacks decorated F1 function).

Unfortunately, the result of this is as above. A failure is created in
errback, it correctly has a traceback on it, but the traceback is then
immediately removed in _runCallbacks!

By the time your code gets its deferred back from calling the
inlineCallbacks decorated F1, the exception has fired, the errback has been
called, the deferred you get has its result sitting there waiting for you,
but the traceback is gone, gone, gone. Without the original traceback, you
end up cursing inlineCallbacks and digging around in what your function
called and what that called, and so on. Not fun :-(

I'll stop for now. I have some suggestions for fixes, but I'm already in
over my head.

BTW, I get the impression that the Twisted core developers don't really use
inlineCallbacks. Is that correct?

Terry

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Tracebacks being dropped from exceptions when using inlineCallbacks

[Phil Christensen]

On Jan 12, 2009, at 8:36 PM, Terry Jones wrote:
I think I've finally gotten to the bottom of why exceptions  
sometimes lose

their tracebacks when using inlineCallbacks.

[snip snip]
I'll stop for now. I have some suggestions for fixes, but I'm  
already in

over my head.

BTW, I get the impression that the Twisted core developers don't  
really use

inlineCallbacks. Is that correct?


I don't have a whole lot to contribute here, except to encourage  
discussion of this issue. I *love* inlineCallbacks, and have found the  
availability of the technique has made me far more inclined to chose  
Twisted as the basis for applications that will require a great deal  
of serial-but-asynchronous operations.


I don't know if I've run into this particular issue, but I know that I  
have run into some error-handling issues when using inlineCallbacks  
that I wasn't able to debug in the usual ways, but I think I ended up  
just fixing the bug that I was trying to catch at the time.


My impression is that there's a reluctance to advertise  
inlineCallbacks too loudly, since using it still requires a thorough  
understanding of Deferreds and asynchronous development to be used  
effectively. New users really need to be starting with the 'old- 
fashioned-way', and even experienced users must be careful that their  
'mental model' of what the code is doing actually reflects reality...


-phil

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python