Project

General

Profile

Packet changed once in addOutPacket()?

Gabriel Rossetti
Added about 4 years ago

Hi all,

I have a strange issue and it is making me go crazy...I receive a packet (iq element with type="get") from a user and process it in my component and generate a reply (iq element with type="result"). I put the resulting packet in the out queue using @addOutPacket()@. I debugged it all the way down and my packet is as I created it. I get to this line in @AbstractMessageReceiver@:

out_queues.get(queueIdx).put(packet, packet.getPriority().ordinal())

and the strange things start happening...lets say that queueIdx = 0 and @packet.getPriority().ordinal() = 3@, once this line executes my packet is not in @out_queues.get(0).get(3)@... then I continue executing the code and I reach this line in @QueueListener@:

packet = queue.take();

and my packet now has a type="error" and the to/from fields were swapped (the rest is the same)... can someone please explain what is going on?

Thanks,

Gabriel


Replies (14)

Added by Gabriel Rossetti about 4 years ago

Ok, there are some threads in the background, I put better breakpoints and followed the execution to the session manager that finds the user's session and sends the packet (?), once that is done the packet is picked up by another thread and it now has the error status...

Added by Gabriel Rossetti about 4 years ago

I think I can safely say my packet is never sent, I used a low level XMPP debugger as the client and it never receives the msg. The server however thinks is receives an error reply.

Added by Wojciech Kapcia TigaseTeam about 4 years ago

Have you tried following your packet in the logs (with debug=server,xmpp)? It's hard to tell why your packet would be converted to error from the scarce information you provide. Can you also share example packet that you are trying to send as well as response generated by Tigase?

Added by Gabriel Rossetti about 4 years ago

Wojciech Kapcia wrote:

Have you tried following your packet in the logs (with debug=server,xmpp)? It's hard to tell why your packet would be converted to error from the scarce information you provide. Can you also share example packet that you are trying to send as well as response generated by Tigase?

Ok, I think I found the issue, I tried to use the EchoComponent to see if it worked and it didn't either, however I saw the error (not sure how I missed it before, probably since the XML I am sending back from my component is quite big), anyways, I traced the error message("The feature is not supported yet.") to the PacketDefaultHandler class :

if (resource == null) {
// In default packet handler we deliver packets to a specific resource only
...
}

and my component is not setting the resource since I want to send it to all of a user's connected sessions. The thing is PacketDefaultHandler

doesn't implement any interfaces and the session manager expects this class, thins makes me think that it swapping the packet handler is not supported, is this correct?

Thanks

Added by Gabriel Rossetti about 4 years ago

I can confirm this is what is happening with my component...

Added by Wojciech Kapcia TigaseTeam about 4 years ago

As per 16. How Packets are Processed by the SM and Plugins - if there are no (pre/post)processors then the default packet handler will be used. Simply implement plugin that will forward your IQ to all resources without strict checking for resource.

Added by Gabriel Rossetti about 4 years ago

Wojciech Kapcia wrote:

As per 16. How Packets are Processed by the SM and Plugins - if there are no (pre/post)processors then the default packet handler will be used. Simply implement plugin that will forward your IQ to all resources without strict checking for resource.

Ok, thanks.

It should be mentioned somewhere that Tigase does not support this out of the box.

Added by Wojciech Kapcia TigaseTeam about 4 years ago

Tigase simply follows specification in this aspect.

Added by Gabriel Rossetti about 4 years ago

Wojciech Kapcia wrote:

Tigase simply follows specification in this aspect.

Ok, we must be interpreting the specification differently, I read:

Implementation Note: It is the server's responsibility to deliver only stanzas that are addressed to the client's full JID or the user's bare JID; thus, there is no need for the client to check the 'to' address of incoming stanzas. However, if the client does check the 'to' address then it is suggested to check at most the bare JID portion (not the full JID), since the 'to' address might be the user's bare JID, the client's current full JID, or even a full JID with a different resourcepart

(http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-to-c2s)

to mean: the server must also support sending to the user's bare JID and thus send to all the connected resources if it is a bare JID.

Added by Gabriel Rossetti about 4 years ago

Should I file a bug report?

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam about 4 years ago

I think that your interpretation of Implementation Note is correct but in same RFC6120 in 10.5.3.2 there is described a way how server should process stanza which contains bare jid in to attribute depending on type of stanza.

If the JID contained in the 'to' attribute is of the form localpart@domainpart, how the stanza is processed depends on the stanza type.

  • For a message stanza, if there exists at least one connected resource for the account then the server SHOULD deliver it to at least one of the connected resources. If there exists no connected resource then the server MUST either (a) store the message offline for delivery when the account next has a connected resource or (b) return a stanza error (Section 8.3.3.19).

  • For a presence stanza, if there exists at least one connected resource that has sent initial presence (i.e., has a "presence session" as defined in [XMPP‑IM]) then the server SHOULD deliver it to such resources. If there exists no connected resource then the server SHOULD ignore the stanza (or behave as described in [XMPP‑IM]).

  • For an IQ stanza, the server MUST handle it directly on behalf of the intended recipient.

This forces server to process this stanza and handle it if possible but also forces server to block delivery of this packet.

Added by Gabriel Rossetti about 4 years ago

Andrzej Wójcik wrote:

I think that your interpretation of Implementation Note is correct but in same RFC6120 in 10.5.3.2 there is described a way how server should process stanza which contains bare jid in to attribute depending on type of stanza.

If the JID contained in the 'to' attribute is of the form localpart@domainpart, how the stanza is processed depends on the stanza type.

  • For a message stanza, if there exists at least one connected resource for the account then the server SHOULD deliver it to at least one of the connected resources. If there exists no connected resource then the server MUST either (a) store the message offline for delivery when the account next has a connected resource or (b) return a stanza error (Section 8.3.3.19).

  • For a presence stanza, if there exists at least one connected resource that has sent initial presence (i.e., has a "presence session" as defined in [XMPP‑IM]) then the server SHOULD deliver it to such resources. If there exists no connected resource then the server SHOULD ignore the stanza (or behave as described in [XMPP‑IM]).

  • For an IQ stanza, the server MUST handle it directly on behalf of the intended recipient.

This forces server to process this stanza and handle it if possible but also forces server to block delivery of this packet.

Yes, that sounds correct of IQ stanzas, agreed. However, PacketDefaultHandler doesn't differentiate between stanza types, although you can argue that you're taking the SHOULD part in the spec and decideing not to implement it.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 4 years ago

Yes, that sounds correct of IQ stanzas, agreed. However, PacketDefaultHandler doesn't differentiate between stanza types, although you can argue that you're taking the SHOULD part in the spec and decideing not to implement it.

This is because for message and presence stanzas we have plugins which handle these packets so default packet handler does not have to worry about them. The problem really is only with iq stanzas, because they have special meaning depending on the iq*'s namespace and even for the same namespace processing of *iq stanzas depend on what is put in the to attribute/address.

Added by Gabriel Rossetti about 4 years ago

Thanks for the explanation, and thanks for the great work!

    (1-14/14)