[Twisted-Python] Local IP and factory shutdown

Gill, Mandeep mandeep.gill at imperial.ac.uk
Wed Jun 23 19:16:13 EDT 2004


>Gill, Mandeep wrote:
>> Hi,
>> I'm in the process of finishing a multicasting RTP streaming media 
>> server and client in Twisted but have encountered several issues that I 
>> can't figure out,
>
>Neat. Note that shtoom (shtoom.divmod.org) also has an RTP
>implementation in Twisted - if you're planning to release your
>code, there may be stuff we can borrow from each other.
>

Actually I extensively studied the Shtoom code before I started as it contained many ideas I could use and explained a lot of Twisted subtleties - I must thank you for that, it's well written and extremely easy to learn from.
The RTP code is borrowed from Shtoom with a few changes to make it support other media formats in an independent manner - at the moment I'm multicasting 5 different MP3 streams around the house with it and it works fine.
The system is my undergrad project, however once it's marked I plan to release the code, there's definitely stuff that can borrowed either way.

>> Firstly, Is there any way to determine your own IP address from with 
>> Twisted, I've looked around everywhere and can't find away to achieve 
>> this except by setting up a loopback connection and reading it from the 
>> transport - but that only gives 127.0.0.1. Is there any way to determine 
>> all available local IPs?
>
>One trick I do in shtoom is put in a ConnectedUDP to the other end, then
>read the local address off that. It's ugly, but gives me the IP of the
>local interface that's being used for this connection. You could also
>use STUN for this, of course. But that won't give you _all_ interfaces.
>
>I don't believe that this is possible in a portable way.

Yeah, I saw that code in Shtoom, however when I tried it I only got '0.0.0.0' - dunno what was going on there. i think at the moment I'll just stick with gethostbyname(gethostname()) for internal IPs and leave the rest for now - NAT seems like too much pain.

>> Oh yeah, there seem to be a few bugs in the current wxreactor support, 
>> most notably with any custom dialog boxes - the OK/Cancel return doesn't 
>> seem to be processed on time and causes a wxDateTime assertion error, 
>> does it work for anyone else?
>
>Neither wxsupport or wxreactor are suitable for heavy lifting. wxsupport
>blocks whenever wx spawns a sub-event-loop (for dialogs, menus, and the
>like) and wxreactor can give no better than the wxTimer's granularity.
>The wx docs promise "no worse than 1s" granularity. On Linux, it doesn't
>seem to be a problem. On Windows, tho, you're boned.
>
>Run the wx mainloop in your main thread, and spawn a second thread to
>run the twisted event loop. You then use callFromThread() to pass things
>to the twisted event loop, and you can make your own shim to pass stuff
>back to the wx event loop. Again, shtoom has this code, in
>shtoom/ui/wxui/ (thanks to Andy Hird for writing this).
>
>
>Anthony

wxreactor seems to be ok for most tasks, I have a fairly complex dynamic GUI running here, however the most random actions will just bring it down. I saw the threaded code in Shtoom and guess that’s the way to go, it just seems a lot of work if wxreactor can be fixed.

Mandeep

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4399 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040624/641041d8/attachment.bin 


More information about the Twisted-Python mailing list