On adding an on-line contact, runs into an infinite loop of Presence-subscribed messages

[GoogleCodeExporter]

I am building a Windows console application, source attached. When I add 
an online contact to my roster, my presence handler keeps 
getting "subscribed" presence messages forever. The output from my console 
application is as below 

On Presence><presence from="u2@rx" to="u1@rx/Jabber.Net" 
type="subscribed" />
On Presence><presence from="u2@rx" to="u1@rx/Jabber.Net" 
type="subscribed" />
On Presence><presence from="u2@rx" to="u1@rx/Jabber.Net" 
type="subscribed" />

What steps will reproduce the problem?

1. Make necessary changes to the source to configure the server, user 
credentials to login and the remote user's id and name

2. Build the application

3. Login with remote user id from another application (e.g. spark)

4. Launch the application and press enter when prompted to add the contact

Can someone please clarify whether this is a defect in the library or 
invalid usage on my part?

I am using the version JabberNet-2.1.0.710.msi 

Best Regards,
Jagan

Original issue reported on code.google.com by jm.bhal...@gmail.com on 21 Apr 2009 at 9:14

Attachments:

• Program.cs

[GoogleCodeExporter]

Looks like I am able to overcome the issue by commenting the following code in 
jabber/RosterManager.cs (Line 286):
            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;

I commented the above code that sends the "subscribe" response to a 
"subscribed" 
message. Will this create any issues?

Original comment by jm.bhal...@gmail.com on 22 Apr 2009 at 11:18

[GoogleCodeExporter]

Which server are you using?  It looks like it has a bug, not implementing RFC 
3921 correctly.

Original comment by hil...@gmail.com on 22 Apr 2009 at 2:35

[GoogleCodeExporter]

Hi hildjj

Thank you for the comment. I am using Openfire 3.6.0. 

Please excuse my ignorance. Based on (my) comment#1, does it not look like a 
client 
issue? When user sends a "subscribe" & receives a "subscribed" in return, it 
response with another "subscribe". Should the server ignore/respond with an 
error 
message?

BTW, if I comment the above code, will it have any side effects? 

Original comment by jm.bhal...@gmail.com on 24 Apr 2009 at 6:39

[GoogleCodeExporter]

See RFC 3921, section 8.2, number 9:

<blockquote>
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 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).
</blockquote>

This got changed in 3921bis, but the subscribe acks should be no-ops, if you 
follow the logic in Appendix A.  
The subscribed ack goes outbound in the both state, with no state change, and 
is forwarded to your contact.  
The contact's server does no state change, and auto-replies back with 
subscribe.  Your server receives the 
subscribe inbound, does no state change, and does not route the stanza.

3921bis could be improved so that a) you can find out that your server does not 
require acks, and b) we avoid 
the round trip.

HOWEVER.  even as things currently stand, Openfire has a bug in that it is 
forwarding the inbound subscribe 
when we're in the both state, according to 3921bis, and is not receiving acks 
appropriately if it's 
implementing 3921.

Original comment by hil...@gmail.com on 24 Apr 2009 at 3:09

[GoogleCodeExporter]

I am having this same problem with the infinite loop.
Please, tell me is there a solution for this ?
I want to user Jabber-Net with openfire but due to this overhead I cannot.
I tried installing the C based JabberD server and it works OK, at least it 
seems so,
no infinite loop and my roster seems to be OK.
Please give me a fix solution for this issue.
Thank you.

Original comment by Gamitech@gmail.com on 17 Jun 2009 at 3:55

[GoogleCodeExporter]

This is a bug in OpenFire, until proved otherwise.  The hack above will get you 
past the problem.

Original comment by hil...@gmail.com on 17 Jun 2009 at 4:04

• Changed state: WontFix