Projects tigase _server server-core Issues #596
Not broadcasting initial presence to offline users (#596)
Closed
Andrzej Wójcik (Tigase) opened 9 years ago
Due Date
2015-11-12

Right now after initial checks of PEP after last refactoring I found an issue with PEP. PEP should by default send last published item on receiving user presence and while this works fine when is online or comes online as user receives info from his own node or receives info from other resource node which is also online then it fails when destination/owner of PEP node user is offline. As I checked this is caused by the fact that Presence processor do not sent presence to offline user and on initial outgoing presence at first send presence probes - it is not broadcasting presence.

As I found there is else clause in line 1704 in Presence processor responsible for broadcasting presence - I think this code should be sent every time, while probe sent in when first is true should be sent only to users subscribed with @to@. - I think this is what we should do based on RFC 6121: Server Processing of Outbound Initial Presence

Also broadcast of presence to offline user is not working - but I think this may be some type of optimization.

I think we should change/fix this as current behavior stops PEP from working. However as I checked current behavior is rather old - I checked commits back to 2012 and code looks were similar since 2012.

Andrzej Wójcik (Tigase) commented 9 years ago

%wojtek - as I remember you added some logic to optimize broadcasting presence to offline users. May this be result of this changes? And what you think about current behavior? Should we change it in default to be same as in RFC6121?

wojciech.kapcia@tigase.net commented 9 years ago

%andrzej.wojcik Yes, there was an optimisation added with #1714 and there are two levels and in general I think this optimisation makes perfect sense (taking PEP aside for a moment) because locally, with the conditions mentioned in the ticket (local users, complete knowledge about the state) it really doesn't make much sense to generate abundance of offline presence / probes if we are certain that those users are offline, which would simply generate offline packets that would be simply dropped moments later.

wojciech.kapcia@tigase.net commented 9 years ago

Addendum - RFC1621 clarified a bit how/when to send probe, but I think that with current handling of presence in Tigase we are still compatible. We cannot skip sending additional probe as handling of in-initial doesn't entail re-broadcasting users presence as response.

Andrzej Wójcik (Tigase) commented 9 years ago

Looks like

is required for PEP to work correctly if user is offline.
Artur Hefczyc commented 9 years ago

Yes, Wojciech is correct. This is an old optimization and it is really useful and improved throughput and performance significantly. Usually less than 50% of contacts are online, on some systems, it goes down to 20% of contacts. So skipping unnecessary presences to offline contacts which we are 100% sure they are offline saves us a lot of traffic.

I wonder, if there is a way to improve current mechanism to make it still work in such a way that it skips offline users but it still compatible with PEP. I mean, presences are skipped in smarter way, that some are skipped whereas those for PEP are not.

What do you think? To be honest I do not have time to read the spec in details to tell whether this makes sense or not.

Andrzej Wójcik (Tigase) commented 9 years ago

I checked once again and PEP works with default settings only if both users are online - this is bad because we would not get response from offline users PEP nodes but it is also good as in most cases we do not need PEP data from offline users (ie. avatars, moods, etc.) as most XMPP clients by default presents only online users.

So to sum up, I think that current behavior is acceptable in most cases and in other we can always disable presence optimization if needed, as I am not able to find any way to make PEP work for offline contacts and still be able to use presence optimization.

I suppose we may close this issue, but I would suggest to add information about this behavior to our documentation.

Artur Hefczyc commented 9 years ago

Ok, good, since we have a way to configure Tigase to work in fully compliance mode, than this is OK.

issue 1 of 1
Type
Bug
Priority
Normal
Assignee
RedmineID
3685
Version
tigase-server-7.1.0
Spent time
18h
Issue Votes (0)
Watchers (0)
Reference
tigase/_server/server-core#596
Please wait...
Page is in error, reload to recover