IM Gateway 1.1.0 Beta

Openfire Plugins Kraken - IM Gateway
81

nice to see the gtalk transport, but subscription handling is not working for me…

A … psi connected directly to gtalk

B … psi uses gtalk transport

on adding contact B from A , B will not get asked to allow subscription and A gets automatically subscritpion

B gets only a presence available but no roster update, on next login of B contact A is on the roster

the same happens on removing contacts

A removes B, B receives only a presence unavailable, but no roster update

on next login of B contact A was removed from the roster

82

MxSan wrote:

I noticed that the XMPP/Google Talk gateway ticked is closed and we can expect this to be in the 1.1.0 release. Will there be another beta, so we can test this before the release.

To be honest, I can’'t wait.

grin I’‘m glad you are excited! I pulled in the contributed work from scriptr but there’‘s still a batch of work to be done to it to make it match some of the changes i made since it was coded. Shouldn’‘t be too far. I’‘ve got one other big thing I am aiming to change for 1.1.0. There’‘s a -lot- of issues closed with this release so it’‘s quite a big one. =) Time permitting, I’‘ll try to get it out ASAP! I’'m excited to see folk using it!

83

notz wrote:

nice to see the gtalk transport, but subscription handling is not working for me…

A … psi connected directly to gtalk

B … psi uses gtalk transport

on adding contact B from A , B will not get asked to allow subscription and A gets automatically subscritpion

B gets only a presence available but no roster update, on next login of B contact A is on the roster

the same happens on removing contacts

A removes B, B receives only a presence unavailable, but no roster update

on next login of B contact A was removed from the roster

I noticed this myself actually. I only tested it in the form of “can I log in, send messages, get messages, etc” Verrrrry basic functionality. Before I release or put out another beta I’‘ll be testing the other basic functionality like the contact list stuff and such. It’‘s definitely a work in progress at the moment. =) It’‘s got a lot of functionality though and I think a lot of the problems you are seeing are related to API changes that it hasn’‘t been ported to yet. =) We’'ll see though.

84

notz wrote:

is there a chance to get away from this duplicate presence messages on login ?

2007.06.04 12:08:39

2007.06.04 12:08:39

2007.06.04 12:08:39

2007.06.04 12:08:39

i know it doesn’‘t matter on desktop clients, but on mobile handsets it’'s a problem.

normally one of these presence messages (available/unavailable) per contact schould be enough or i’'m wrong ?

hi notz,

i am running a mobile application too and i used to have that problem until today. I have found the solution for the duplicate presences and also duplicate iq packets (This happens,int the first connect after you restart the openfire server) in every gateways. Tomorrow i will be testing with my team.

85

Only the first connect?

Are you referring to the fact that the gateway sends presences for contacts as they come online, and then the client typically sends a probe? (i don’‘t really understand the logic of the probe but hey, it seems to be the trend nowdays) When I first started doing this, as folk came online they watched for presences. They didn’‘t “log in, do everything, wait until -they- were ready for presence, and -then- throw a crapload of probes”. None-the-less, I don’‘t know that that’'s the issue you are referring to. =)

86

hi daniel,

i am talking about duplicate iq packets in the first connection and about lots of presence packets of just one user.

duplicate iq problems: when a user first connects to any service (msn, gtalk, icq etc), the gateway sync the roster. In this process, you get two iq packets per your contact. first iq contains only the jid with a “none” subscription, and then gateway sends another iq packet, which has the name of the user, for this user. So the first iq is sent by openfire because of the following code in the BaseTransport class.

// Create new roster item for the gateway service or legacy contact. Only

// roster items related to the gateway service will be persistent. Roster

// items of legacy users are never persisted in the DB.

RosterItem gwitem = roster.createRosterItem(contactjid, true, contactjid.getNode() == null);

in this code, while creating new roster item, gateway pushes the new roster item to the client, which i believe that it shouldn’'t. Because in the next lines, it will push the roster with:

roster.updateRosterItem(gwitem);

so the gateway should call the “createRosterItem” method with false in the 2nd argument, which decides pushing the newly created roster item.

lots of presence packets: in fact this is not a bug or error. but it is a thing that can be optimized. while we start the services (msn, gtalk etc, ‘‘i do not know how you call these’’), their listeners begin to listen and process what they get as soon as possible. but for the presences changes, we need to make presence listeners wait until we sync the rosters. Because in the “syncUsers()” method, we already send the initial prences of our roster items. (of course, this is not a solution for the msn UBX packets, it is normal that you can get 2 presence for the user anyway.)

as a conclusion, by fixing (maybe wrong word) the above codes, i can sign an msn users, that has a 21 contacts, with just ~7kb in stead of ~18kb. Since my client is mobile ( http://www.cepteki.net - english version is in progress) 11kb is really a big traffic.

after my tests, i will post my codes in here, so you can test that also.

(sorry for my poor english, i hope i was clear.)

87

scriptr wrote:

hi daniel,

i am talking about duplicate iq packets in the first connection and about lots of presence packets of just one user.

duplicate iq problems: when a user first connects to any service (msn, gtalk, icq etc), the gateway sync the roster. In this process, you get two iq packets per your contact. first iq contains only the jid with a “none” subscription, and then gateway sends another iq packet, which has the name of the user, for this user. So the first iq is sent by openfire because of the following code in the BaseTransport class.

> // Create new roster item for the gateway service or legacy contact. Only
> >

> // roster items related to the gateway service will be persistent. Roster
> >

> // items of legacy users are never persisted in the DB.
> >

> RosterItem gwitem = roster.createRosterItem(contactjid, true, contactjid.getNode() == null);
> >

in this code, while creating new roster item, gateway pushes the new roster item to the client, which i believe that it shouldn’'t. Because in the next lines, it will push the roster with:

roster.updateRosterItem(gwitem);

so the gateway should call the “createRosterItem” method with false in the 2nd argument, which decides pushing the newly created roster item.

Hrm. And so then update will fire the only “push” so to speak. Yeah I see nothing wrong with that, I’'ll do that. Thanks! GATE-241 (not going to close it until I actually commit my code to SVN ;D )

lots of presence packets: in fact this is not a bug or error. but it is a thing that can be optimized. while we start the services (msn, gtalk etc, ‘‘i do not know how you call these’’), their listeners begin to listen and process what they get as soon as possible. but for the presences changes, we need to make presence listeners wait until we sync the rosters. Because in the “syncUsers()” method, we already send the initial prences of our roster items. (of course, this is not a solution for the msn UBX packets, it is normal that you can get 2 presence for the user anyway.)

as a conclusion, by fixing (maybe wrong word) the above codes, i can sign an msn users, that has a 21 contacts, with just ~7kb in stead of ~18kb. Since my client is mobile ( http://www.cepteki.net - english version is in progress) 11kb is really a big traffic.

after my tests, i will post my codes in here, so you can test that also.

(sorry for my poor english, i hope i was clear.)

I would certainly love to see whatever code you’‘ve worked up for this, BUT I’‘ve actively been working on a new way of handling the buddy list so to speak that will cut down on these presence notifications tremendously. Basically I’‘m implementing a generic buddy item (that gets overrided by each transport if the want to store special info for their own purposes about a buddy) and a buddy item manager. Presence notifications are only auto-sent if there is a change. If I get three online pings from the legacy service and nothing is different then by god I’‘ll only send one. =) So I hate to tell you that after it sounds like you’‘ve already worked out a solution, but regardless I’'d love to see your approach as well ''cause I always like to see different ideas and such regardless of if I end up using them!

Daniel

88

for handling the presences, i have modified the msn library (jml.jar) and added some extra methods like

-MsnContactImpl

getOldCurrentMedia()

getOldPersonalMessage()

and also, i use MsnUserImpl to get the oldDisplayMessage and oldStatus. By the help of these methods, now i can track the users’'s info, so that i can decide if i need to push or not.

This is also a solution for duplicate msn server’‘s presence commands. If you check you debug, you can see that msnp 11 can send one or more presence commands for one user. So sometimes, openfire need to send you “4” presence message for the same user. But now, it can’'t

Now the only problem is the seperate presences i get from msn server. They are; NLN (FLN, IDL etc.) and UBX. I think there is no solution for that.

Anyway, my tests are still in progress, i will let you know the updates.

89

Oh cool, as the maintainer of Java-JML, I’‘d be happy to pull in your changes to that project as well. =) I’‘m almost done with my base mods for the new and improved buddy handling hotness. Will commit once I’‘m comfortable with it. At the moment I’‘ve only applied it to MSN since it seems to be a big problem causer. It’‘ll be my test case. I plan on getting that going, making sure my mods don’‘t screw over the other transports, committing, and then working on the other transports. =) I’'m pretty excited. It cleans up what the transports themselves have to do quite a bit.

90

GATE-243 for the multiple messages issue btw

91

Daniel,

I’'ve tested IRC MUC support:against ircd running on OS Sun Solaris 8

Openfire version 3.3.1 running on XP 2K3

Java version: 1.6.0 Sun Microsystems Inc

Client: Psi 0.10

ircd was initially configured to block incoming traffic

The gateway threw an NPE . Log file gave hint “user cannot be authorized” At the beginning it was not clear what the problem was related to… After modifying ird.conf we could successfully log on and use the MUC to channel feature.

More testing will be done later, this is just a quick feedback.

Thanks

92

Awesome, thanks! I recorded GATE-251 regarding the NPE =)

93

grutto wrote:

Daniel,

I’'ve tested IRC MUC support:against ircd running on OS Sun Solaris 8

Openfire version 3.3.1 running on XP 2K3

Java version: 1.6.0 Sun Microsystems Inc

Client: Psi 0.10

ircd was initially configured to block incoming traffic

The gateway threw an NPE . Log file gave hint “user cannot be authorized” At the beginning it was not clear what the problem was related to… After modifying ird.conf we could successfully log on and use the MUC to channel feature.

More testing will be done later, this is just a quick feedback.

Thanks

Do you happen to have the NPE stack trace available? It would help to see the whole thing =)

94

I posted this as its own thread, but I might as well keep it all under the Beta thread:

Hi,

Is anybody else getting problems in 1.10 with respect to:

a) obtaining online presence on a high-volume yahoo account. I have a Yahoo account that has 90 contacts. Where as Pidgin and Yahoo Messenger see 60-70 people online (which was the correct number of people online), Openfire only see about 20. Is anybody else getting this? This also occurred in previous version of the gateway.

b) adding a new buddy but not having a corresponding yahoo buddy acceptance dialog on Yahoo Messenger? I’‘ve tried multiple times to add newly created (aka, they have no buddies and never have been asked to buddy up) to each other’'s buddy lists with no luck.

c) Signing in the first time to a newly compiled openfire server not finding all the folders of a yahoo user? After the first time, all the folders show up correctly in spark.

95

Which 1.1.0? 1.1.0 Beta or 1.1.0 Beta 2?

96

Sorry, disregard the other thread, we’'ll work off this one I guess.

This was your source from yesterday, June 28th, which was checked out from the trunk, compiled, then run as a plugin on openfire 331. I don’'t think I can categorize it purely as Beta 1 or Beta 2, in that case.

97

I’'m definitely seeing the yahoo issue on my account, currently have >100 people on the list and can only see 15-20 at any given time.

Tried Spark 2.5.3-4 and Pidgin, same results.

Working with 1.1.0 b2 release.

98

Is there a way to attach a debugger to openfire to step through it? I don’‘t care what IDE you are using to do it if you can, I’'ll fire anything up right now to investigate.

99

Hey jadestorm,

I have a user with 128 users. With Yahoo and Pidgin, 95 out of 95 show up. With Spark, it’‘s 19 that show up. Maybe it is my server, could I possibly connect to a server you have set up personally to show you? If I can get clearance, I’‘ll give you the account I’'m testing with.

100

Update, after keeping Spark online for a while, the number of 19 people online has gone up to 65. It’‘s getting better, but it shouldn’'t take this long and still missing 30 people.