resource conflict when changing client network settings

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run XMPP client attached to prosody
2. activate vpn on client side, this cases the client (smack) to throw an 
exception. Not a problem as that is expected. But then ...
3. Restart client. 409 now gets thrown. Game over.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
0.9.4. Ubuntu 14.04

Please provide any additional information below.
Once conflict(409) starts up, the only way to clear it is by restarting the 
server. It does not appear that "kill_old" for conflict_resolve option works.

I am using anonymous connections.

Original issue reported on code.google.com by vancle...@gmail.com on 2 Sep 2014 at 1:57

[GoogleCodeExporter]

Oh yeah, this is when connected to a muc room.

Original comment by vancle...@gmail.com on 2 Sep 2014 at 1:58

[GoogleCodeExporter]

Hi, thanks for the report!

As far as I can tell, what you describe is the expected behaviour.

Because you are using anonymous authentication, every connection gets its own 
unique/random username. Resource conflicts can only happen for multiple clients 
sharing the same account/username.

The conflict (409) error you are seeing is from the MUC room. Because the first 
client did not close its connection cleanly, it has not yet timed out, and 
still occupies the MUC room with the same nickname as the new client is trying 
to use.

The only valid solutions to your problem right now that I can see are either: 
1) use a different nickname (you could do this automatically, append a random 
number or an underscore, or something when you receive a conflict error from 
the MUC)  or 2) don't use anonymous authentication, then Prosody will know you 
are the same user and will let you share the nickname in the MUC until the old 
client connection times out.

I hope this helps!

Original comment by MWild1 on 2 Sep 2014 at 6:43

• Changed state: Invalid

[GoogleCodeExporter]

What is the timeout? Is this configurable?
 On Sep 2, 2014 2:44 PM, <lxmppd@googlecode.com> wrote:

Original comment by vancle...@gmail.com on 3 Sep 2014 at 6:37

[GoogleCodeExporter]

There is no single timeout - I'm afraid predicting when a ghost TCP connection 
will timeout is non-trivial, because it depends on so many factors in the OS 
and the network layers. We have plugins to actively ping clients to help with 
this, it would not solve your problem - you would always still have the 
potential for a conflict depending on the timing.

There is one way you could avoid a conflict with ghost sessions. Prosody could 
ping the MUC occupant you are trying to replace, when you try to replace them. 
If they don't reply within X seconds, it kicks them from the room and lets you 
in. If they reply, it sends you a conflict error. There are drawbacks to this 
approach - e.g. legitimate clients might get kicked (for example mobile clients 
currently in a tunnel). I'm not sure we'd ever do this by default, but a plugin 
could do it. Not sure how easy it would be.

Original comment by MWild1 on 3 Sep 2014 at 8:05