Dnia 2012-09-12, śro o godzinie 20:22 +0200, Alexandre Jousset pisze: > > How do you recover from this split when parts get reconnected? :-) > > Well, why not behave as if it was a "normal" bind? > > I haven't thought a lot about it, I definitely need to do it, > but in my first thoughts there can be collisions on JID's resource > parts. This is why I asked if the resource could be renamed *after* a > session is started...?
You're right. We might have resource level collisions on daily basis. If '[email protected]/foobar' connects to two different c2s we need to detect it at the router level. Currently we do it on c2s level by generating new resource: https://github.com/Jabberd2/jabberd2/blob/master/c2s/c2s.c#L297 and sm level by disconnecting previous session: https://github.com/Jabberd2/jabberd2/blob/master/sm/sess.c#L144 https://github.com/Jabberd2/jabberd2/blob/master/c2s/c2s.c#L1135 We would need to modify sm to react on router denied bind and disconnect c2s session. We could have bind-revoked messages in the protocol. If the target of bind-revoked message is user JID we disconnect the user session (or all sessions if bare-JID). If it is sm itself (via bound domain name) we shutdown domain handling in sm. If it is the component name itself, we shutdown the component. Looks simple. Too simple? ;-) In real life the "incoming" part of the "split" would get disabled parts already handled on the "accepting" part, and all disconnected sessions would have to cope. In case of user sessions - the client usually just reconnects. (To already "fixed" mesh.) -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
