Hey Walter,
Thanks for pointing this out. I will forward this info to Jeff that is the STUN/Jingle/VoIP resident expert.
-- Gato
That's great - I look forward to testing 3.1.0. From scanning the ChangeLog, it seems that the problems with closing the connection haven't been resolved yet (there's a hardcoded time that it waits in the hope that everything will be written to the channel, however, that's not guaranteed - I'm using Smack for some non interactive communication and I find I need to wait a second or two just to be able to guarantee messages actually go out). It'd be really nice if that could be addressed...
Hmm... one thing we could do is allow a property to be set where it would wait until the outgoing queue is empty before finalizing the connection close vs. having a max number of seconds. Is that the behavior you're looking for?
What I'm looking for is that if I call disconnect() that I can be garanteed that all messages were actually sent. My application has a number of custom jabber commands that get send to various daemons. So, the usage pattern is log in with daemons credentials, send some messages, disconnect. If I can be sure that I don't have to put a sleep before I call disconnect, I'll be very happy :-). To my taste, that makes perfect sense as a default behavior, but it could be controlled by a property or an extra boolean argument to disconnect (e.g. exitImmediately). Thanks for looking into this :-).
Hi Matt,
first of all, I'd like to thank your for restarting the work on Smack. I am looking forward to test 3.1.0. b1 and will post observations in the community.
Since you have started the 3.1.0 branch, I would like to ask you to taka a look at the hard coded references to stun.xten.net in the Smack code. From my understanding this URL is used as a fall back for STUN. I am using Spark in a corporate enviroment and have some trouble with our network security team regarding unauthorized connections to stun.xten.net. I would suggest to have that URL as a configurable entry instead of a hard coded reference. The community has reported the issue, but no bug was opened and most of the community members are unsure about the impact of simply removing the URL from the code.
Walter Ebeling