Done. Bernd
Bernd Fondermann wrote: > On Sat, Mar 13, 2010 at 19:15, Jean-Sebastien Delfino > <[email protected]> wrote: >> Bernd Fondermann wrote: >>> On Thu, Mar 11, 2010 at 10:31, Bernd Fondermann >>> <[email protected]> wrote: >>>> On Thu, Mar 11, 2010 at 09:51, Bernd Fondermann >>>> <[email protected]> wrote: >>>>> On Thu, Mar 11, 2010 at 09:06, Jean-Sebastien Delfino >>>>> <[email protected]> wrote: >>>>>> With ejabberd and gtalk (and IIRC jabberd too), if I send a message to >>>>>> [email protected] for example, and jdoe is listening through multiple client >>>>>> resources, like [email protected]/desktop, [email protected]/laptop, >>>>>> [email protected]/phone, he'll get a copy of the message on each resource. >>>>>> >>>>>> From what I can see in my test environment, Vysper seems to behave >>>>>> differently and only delivers the message to one of the connected >>>>>> resources. >>>>>> >>>>>> Is there a way to send a message to all connected resources like the >>>>>> other >>>>>> servers do? or did I miss anything in the way I've constructed the >>>>>> XMPPServer [1]? >>>>> Looking at the code, this is the way it's implemented. >>>>> However, you could send a <message type="headline" > and this would go >>>>> to all resources. >>>>> >>>>>> I've checked the XMPP specs: >>>>>> >>>>>> XMPP Core - RFC 3920 Section 10.5 [2] says >>>>>> 'should deliver the stanza to at least one of the connected resources' >>>>>> >>>>>> XMPP IM - RFC 3921 Section 11.1 [3] says >>>>>> 'MAY choose between them or MAY deliver the message to all such >>>>>> resources' >>>>>> >>>>>> Then XEP-0259 [4] introduces a protocol extension allowing device >>>>>> resources >>>>>> to control which one should receive the messages. >>>>>> >>>>>> So, I'm not an XMPP expert... but unless Vysper implements XEP-0259 -- >>>>>> or >>>>>> another relevant XMPP extension from this spec maze :) -- I think it >>>>>> would >>>>>> make sense to send the message to all connected resources (unless they >>>>>> have >>>>>> indicated a negative priority, as described in [3].) >>>>> ... unless of course you send to a resource directly. >>>>> >>>>>> Thoughts? >>>>> I'm undecided. I'll go and figure. >>>> see >>>> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-05.html#rules-barejid-resource-message >>>> and VYSPER-179 >>>> >>>> We really have the choice. Means we should give users the choice and >>>> make it configurable. >>>> After implementing the functionality, of course :-) >>>> Also, what is not working properly right now is how the prio >>>> resolution tie is resolved. >>>> >>>> I'll have a look. >>> In trunk, should now work as you suggested. >>> >>> Bernd >> Thanks, it works! until I disconnect and reconnect some of the clients. >> >> That may be a different issue, but it looks client sessions are not removed >> from the list of delivery targets when the clients disconnect. >> >> From the log: >> >> 09:58:05,347 | WARN | >> org.apache.vysper.xmpp.delivery.inbound.DeliveringInboundStanzaRelay | >> multiplexing: 6 sessions will be processing message.body.hey >> >> shows 6 sessions, although I only have 2 clients connected right now. >> >> Once I disconnect a client messages are not delivered anymore to all the >> other connected clients. >> >> I'll investigate more if I find some time over the weekend and post what I >> find here... > > Thanks for reporting this! > > I can reproduce and will commit a simple fix as soon as possible. > > Bernd >
