[Twisted-Python] Local IP and factory shutdown
mandeep.gill at imperial.ac.uk
Wed Jun 23 19:16:13 EDT 2004
>Gill, Mandeep wrote:
>> 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).
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 4399 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040624/641041d8/attachment.bin
More information about the Twisted-Python