Jabber Stream ID problem

dmotloch · ‎10-10-2017

Cisco IM&P 11.5.1SU3

We are trying to send multiple xmpp messages from a bot, if we do it to quickly we get the following response:

(instance 1) Connected as xmpptest1@lhsc.on.ca/48f0ec71e1e1d1e9335bb90cf83d801ad7b01967

(instance 2) Connected as xmpptest1@lhsc.on.ca/48f0ec71e1e1d1e9335bb90cf83d801ad7b01967

(instance 2) Error: stream error: conflict

(instance 2) Disconnected from 172.20.48.45:5222: end of 'XML' stream encountered

1/ Can the server side of Jabber be configured to always assign a new stream ID/resource identifier to each new connection?

2/ Alternatively, can we find out if there’s a guaranteed minimum delay time between connections (eg. 100ms) that will guarantee that a new ID is assigned?

dstaudt · ‎10-10-2017

I believe it would be advisable to maintain a constant and consistent connection (TCP+XMPP stream) for sending consecutive messages, especially if messages will be sent rapidly.

Not aware of any details on the IM&P server's internal rules for stream id creation/timeout - trying to rely on such a timer would be non-deterministic in any case.

dmotloch · ‎10-11-2017

if I delay between messages by 1 second (haven't tested delaying less time) then I get unique session IDs - seems strange? Any other ideas? Does anyone know how long I have to delay to get unique session IDs?

dstaudt · ‎10-11-2017

Update, it looks like you were successful via the below suggestion:

It looks like per the XMPP spec, the client application can specify the resource ID itself upon connection/binding, rather than request the server to create one. If you are able to control the connection/bind sequence at that low a level, that would avoid the issue, I think: https://xmpp.org/rfcs/rfc3920.html#bindt looks like per the XMPP spec, the client application can specify the resource ID itself upon connection/binding, rather than request the server to create one. If you are able to control the connection/bind sequence at that low a level, that would avoid the issue, I think: https://xmpp.org/rfcs/rfc3920.html#bind