powered by Jive Software

Register component to msn gateway (again)

I’‘ve been researching this problem (which I posted as a much broader question some time ago) and I’'ve come to this:

If I send a presence packet with no type from my component to the msn gateway it does not get there at all, but presence packets with type (like subscribe or subscribed) and iq packets do get to the gateway quite fine. I’‘ve come to the point that I can register my component to the msn but I have no way to tell the gateway that I’'m online.

Is there any design reason for that behavior or is it that no one tried that before?

If there is no design or protocol barrier I’'d like a hint about which classes should I look in order to change that behavior to the one I need

Regards,

Jorge

Jorge,

How are you able to verify that the presence packet isn’‘t delivered to the component? Also, is this a gateway that’'s acting as an external component?

Regards,

Matt

are you subscribing to the component itself by sending a subscribe packet to msngateway.your.server after registering?

Easy, I just sniff the packets in the local tcp connection between the component and jive. The msn gateway is PyMSN-t so it’'s is external, my component is a plugin so it is internal.

By the way, is there an internal msn connector that I’'m not aware of?

Thank you for your time

Regards,

Jorge

When you sniff the packets between the two are you seeing the presence packets or not?

Here I send the log between jive and the msn gateway (port 10015 is jive and 46483 is msn):

T 127.0.0.1:10015 -> 127.0.0.1:46843

127.0.0.1:10015

127.0.0.1:10015


T 127.0.0.1:10015 ->

127.0.0.1:46843

T 127.0.0.1:46843 -> 127.0.0.1:10015


T 127.0.0.1:10015 ->

127.0.0.1:46843

T 127.0.0.1:46843 -> 127.0.0.1:10015


T 127.0.0.1:10015 ->

127.0.0.1:46843

Hmm, I don’‘t see any obvious reasons why your presence packets should fail. I can only assume that the routing logic in the server itself has some issues. Perhaps it doesn’'t correctly account for inter-component communication.

This is Gato’‘s area of expertise and he’'s on vacation this week. So, I filed JM-375 and we should get an answer from Gato on it next week.

Regards,

Matt

T 127.0.0.1:46843 -> 127.0.0.1:10015

<presence to=’‘test@colas.devel.pbxip.net’’

from=’‘msn.devel.pbxip.net’’ type=’‘unavailable’’/>

Why is the gateway saying its unavailable? That would be the answer as to why the server is not forwarding packets to it. Also I see msn subscirbing to your presence but not you subscribing to msn. In other words i dont see the subscribed back from msn.

I also thought that, but I also sniffed a correct registration to the gateway by a client, and it always sends those unavailable packets until it sees the presence from the other side. This is also confirmed by the msn gateway’'s log:

08/17/05 - 13:43:30 - PyTransport: Sending unavailable presence to non-logged in user "test@colas.devel.pbxip.net"

then my quesiton would be is this directed presence of unavailable then affecting Messenger’'s forwarding of presence packets. Id have to go in and check the messenger code but if anyone is familiar with it offhand: Does Messenger think then that the gateway is unavailable? And is that why it is not forwarding the presence packets?

I’‘ve been working on a gateway framework to take care of the details of registration, presence management, etc. I’'ve seen the behavior that when an “unavailable” packet is sent, Messenger will stop forwarding any packets until a login comes around from that entity.

For example, the gateway (my implementation) is required to send an unavailable if the user unregisters (along with an unsubscribed and unsubscribe). In my testing, unavailable never makes it and if I send it first, than the unsubscribe(d) won’'t make it easier.

So, the user unregisters. Then the gateway sends a directed unavailable to the user? If that is the case and other presences aren’'t getting through that would seem it would be the same case then as is be experienced with the msn gateway.

Hey guys,

Thanks for reporting this issue. The problem has been fixed so you can try again with the next nightly build. Let me know how it goes.

Regards,

– Gato

When will the next nightly build be available?

In http://www.jivesoftware.org/nightly.jsp the last I see was from August 17

Hola drencrom,

A new build was just added so check out the nightly builds page again.

Gracias,

– Gato

I tried it and it’'s working fine now. I was finally able to register my component in the msn network.

Thank you!