Le 17/09/2012 10:05, Tomasz Sterna a écrit :
Dnia 2012-09-16, nie o godzinie 23:06 +0200, Alexandre Jousset pisze:
Err... Sorry again, but in case of delivery I've found that:
http://xmpp.org/rfcs/rfc3921.html#rules (see 11.1.4.1 for messages)...
This page was what I saw before posting
Dnia 2012-09-17, pon o godzinie 10:55 +0200, Alexandre Jousset pisze:
The question was:
But then - what happens if two resources of the same priority get
connected to two different sm instances?
After reading the link I posted in my previous message, I
don't see what
Le 17/09/2012 11:02, Tomasz Sterna a écrit :
Dnia 2012-09-17, pon o godzinie 10:55 +0200, Alexandre Jousset pisze:
The question was:
But then - what happens if two resources of the same priority get
connected to two different sm instances?
After reading the link I
Le 17/09/2012 13:10, Tomasz Sterna a écrit :
Again.
There is 'u...@example.com/foo' resource with priority 1 bound on sm1.
There is 'u...@example.com/bar' resource with priority 1 bound on sm2.
1. There is an incoming iq-get request for u...@example.com vCard.
- it is being sent to sm1 and
Dnia 2012-09-17, pon o godzinie 14:29 +0200, Alexandre Jousset pisze:
I see a possibility for this but it looks hackish...: router
looks into the messages when there are more than 1 possible recipient
component (in user@domain case). If it is an IQ = it generates the
error itself. Or
Le 14/09/2012 16:08, Tomasz Sterna a écrit :
Let's say, that we won't allow several SM instances handle resources of
the same user.
How? This needs tiny modification of C2S/SM protocol. Instead sending
the user session creation request to the user domain, let's send it to
the user bare-JID.
Dnia 2012-09-17, pon o godzinie 17:25 +0200, Alexandre Jousset pisze:
(There is a possibility of race - handling several session creation
requests by router and pushing to several random SMs, before first
one
binds user bare JID.)
This case could be resolved if the router
