powered by Jive Software

Jabber-Net library and Openfire 3.6.4

I am using Jabber-Net library ( JabberNet-2.1.0.710.msi downloaded from http://code.google.com/p/jabber-net/downloads/list ) and OpenFire 3.6.4 downloaded from here.

I use the jabber-net with visual studio and I have a problem.

When I want to add a new contact to my roster, I get an infinite of subscribe presence’s from the server.

I let the OnPresence be handled default by the Jabber-Net lib, I do not register a callback. (but when I register it I see the packets).

When I use jabberd server it works fine.

It is very easy to reproduce the bug (I think it is a bug)

If you download the sources of JabberNet they have an example of application made using JabberNet lib (i put compiled app in attachament, this is just how my app add a new contact).

I open Example, connect to server with user1, then I use Spark and connect with user2.

When I add from Example-app user2 to user1’s roster, after I click accept in spark (to accept the subscription), Example-app keeps on getting presence subscribe requests from server, and my processor is 100% busy.

I really want to use OpenFire server for my app, but this kind of overhead is unnacceptable.

How should this be handles.

As I see from the sources this is how OnPresence method is handled by default in the Jabber-Net lib:

Tell me if there is something wrong with it, or tell if there is something I should do to configure Openfire to work

Thanks.

private void cli_OnPresence(object sender, Presence pres)
{
PresenceType typ = pres.Type;
switch (typ)
{
case PresenceType.available:
case PresenceType.unavailable:
case PresenceType.error:
case PresenceType.probe:
return; //doesn’t matter with these
case PresenceType.subscribe:
switch (m_autoAllow)
{
case AutoSubscriptionHanding.AllowAll:
ReplyAllow(pres);
return;
case AutoSubscriptionHanding.DenyAll:
ReplyDeny(pres);
return;
case AutoSubscriptionHanding.NONE:
if (OnSubscription != null)
OnSubscription(this, this[pres.From], pres);
return;
case AutoSubscriptionHanding.AllowIfSubscribed:
Item ri = this[pres.From];
if (ri != null)
{
switch (ri.Subscription)
{
case Subscription.to:
ReplyAllow(pres);
return;
case Subscription.from:
case Subscription.both:
// Almost an assert
throw new InvalidOperationException(“Server sent a presence subscribe for an already-subscribed contact”);
case Subscription.none:
if (ri.Ask == Ask.subscribe)
{
ReplyAllow(pres);
return;
}
break;
}
}
if (OnSubscription != null)
OnSubscription(this, ri, pres);
break;
}
break;
case PresenceType.subscribed:
// This is the new ack case.
Presence sub_ack = new Presence(m_stream.Document);
sub_ack.To = pres.From;
sub_ack.Type = PresenceType.subscribe;
m_stream.Write(sub_ack);
break;
case PresenceType.unsubscribe:
// ack. we’ll likely get an unsubscribed soon, anyway.
Presence un_ack = new Presence(m_stream.Document);
un_ack.To = pres.From;
un_ack.Type = PresenceType.unsubscribed;
m_stream.Write(un_ack);
break;
case PresenceType.unsubscribed:
bool remove = true;
if (OnUnsubscription != null)
OnUnsubscription(this, pres, ref remove);

if (remove)
Remove(pres.From);
break;
}
}

PS:

It works well when I delete (unscribe a contact from my roster).

The problem only persists if a subscription request is made, either from Example-app either from Spark.

Please let me know if there is any version of openfire that does not have this bug, or if there is going to be a patch released for this bug

Thank you

The only thing i can do is to file this as OF-38. Not a bug report as i can’t confirm it myself.

We are having the same problem with Openfire 3.6.4 and Jabber-Net.

http://www.igniterealtime.org/issues/browse/OF-38 and more importantly http://www.igniterealtime.org/issues/browse/JM-384 seem to be the defects, in case anyone else is looking at the problem.

Looking at the RFC, i think openfire is incorrectly not ignoring the last subscribed message.

http://tools.ietf.org/html/rfc3921#section-7

9.  Upon receiving the presence stanza of type "subscribed", the user
       SHOULD acknowledge receipt of that subscription state
       notification through either "affirming" it by sending a presence
       stanza of type "subscribe" to the contact or "denying" it by
       sending a presence stanza of type "unsubscribe" to the contact;
       this step does not necessarily affect the subscription state (see
       Subscription States (Section 9) for details), but instead lets
       the user's server know that it MUST no longer send notification
       of the subscription state change to the user (see Section 9.4).

When openfire gets this affirmation “subscribe”, it starts the subscribe process over again instead of ignoring the response.

Looking at the code and the rfc http://xmpp.org/rfcs/rfc3921.html#roster

I think the issue is in the PresenceSubscribeHandler line 141 where it auto-delivers a “subscribed” packet if the user is already subscribed to a roster. I don’t think it should do this because it will break number 9 in the rfc under roster, where it the client sends out the “subscribe” to an already subscribed contact and the server eats it.

Anyone else read this a different way?

I agree. I just committed a fix based on your recommendation as part of OF-38.