Local IP and factory shutdownTo find my one true external ip address I used http://www.showmyip.com/ they also have http://www.showmyip.com/xml/ which should be very easy to fetch and process with Python. ----- Original Message ----- From: Gill, Mandeep To: twisted-python@twistedmatrix.com Sent: Wednesday, June 23, 2004 12:35 AM Subject: [Twisted-Python] Local IP and factory shutdown 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, 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? Also I have a problem in shutting down Factories - currently I shut them down by calling the doStop method, which seems to call stopFactory but this is an abstract method used just for safe user shutdown, right? As far as I can tell, the Factory is still bound to the reactor, and am I still able to connect to it having called doStop. How do I stop the protocol from even listening on ports? 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? Thanks for any help Mandeep Gill ------------------------------------------------------------------------------ _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

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.

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.

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 -- Anthony Baxter It's never too late to have a happy childhood.

Itamar Shtull-Trauring writes:

On Tue, 2004-06-22 at 18:35, Gill, Mandeep wrote: (...)

...

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?

wx integration is broken. As far as I can tell best option is running it in separate thread... or better yet, not using wx at all.

Note that we've had fine luck using the standard reactor and iterating it via a wxTimer, based off of the entry at: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/181780 You do end up enforcing some time granularity on the network due to whatever timer frequency you pick, but so far it's been more than sufficient for our applications. The tweaks we made were to shorten the timer to about 150ms, and explicitly stop the timer and reactor in an OnExit() routine. I also experimented with additional reactor iterations in an Idle handler, but found that they really didn't make that much of a difference in network performance. Note that most of our wx-based applications are GUI interfaces, so the interface is the primary application with the networking in support of that. For those whose application is the opposite (the GUI is an add-on to the protocol support) it might be more limited by the impact of the periodic reactor execution, I'm not sure. -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/

Anthony Baxter writes:

On windows, I've seen as bad as 100ms per timer. When you're trying to send one packet every 20ms, this is less than good.

Well, as I said, our application was a GUI with networking in support of its GUI functionality, so its primarily triggering network operations in response to GUI actions, and doesn't have a heavy network load running simultaneously. So it does depend on your application. Note also that if you do have a heavier network load, I'd expect that a combination of including reactor iteration in an idle event handler, as well as boosting the timeout slightly in the iterate() call that runs on each timer would go a long way to covering you. Either that or as noted elsewhere, run the wx message loop in a separate thread (in the 2.5.x series, its easier to control the GUI thread since it's where the App object is instantiated and not where the wxPython module is imported). I'll be happy to replace this method with something like wxreactor once the latter (or equivalent) is stable. But for the time being, the timer approach has proven sufficient to our needs. -- David