I’'m having some serious problems only when I use an account with a large (~120) aol buddies. When I log in with the large AIM buddy list, I got the error message of “You are talking too fast …” from AIM transport and very often it will disconnect my session.
I’'m using smack-1.1.1, and jabber-1.4.2 with aim-transport-stable-20030314.
I wonder if anybody out there has similar problem and how it gets resolved, or anyone can shed some lights on what is happening and points some possible solutions.
The trace showed lots of PRESENCE packets received after I log in, and then followed by lots of error MESSAGE with “You are talking too fast. Message has been dropped.”.
This sounds like a server problem and not any issue with Smack unless you are trying to send messages out too quickly. If you do send too many messages, I believe jabberd will start dropping them to prevent resources overload.
Yup, on Jabberd the setting is called karma and it determines how quickly you can send data over a connection. You can play with the karma settings on your server if you have admin priviledges.
I actually played a bit the karma setting, but it looks those error MESSAGE’'s are still there, and coming from AIM-t not jabberd. The debug mode of AIM-t showed something saying “[AIM] rate limit (paramid 0x0002): curavg = 1619, maxavg = 6000, …”
The fact is that I didn’'t even start sending any of my messages yet. Just by logging in, the flood of PRESENCE from all my aol buddies (~120) caused this situation immediately. I believe the overloading flow is from the other direction (not from client). Still wondering, however, what is the mechanism here and if there is a way I can control the pace of those PRESENCE on smack side. Or if there is a way to tell server to send PRESENCE in smaller groups with delays in between?
In general, how the large buddy list is being deployed in real life? With the smack-1.1.1/jabber-1.4.2/jabber-1.4.2, this rate limit problem is reproducible every time with a large buddy list.
Desperately seeking a solution. Welcome for any idea/discussion/suggestions!
I’‘m fairly certain that Smack has no control over this issue and that there aren’‘t any possible workarounds that we could make. So, I’‘d recommend contacting the authors of AIM-T to see if they’'ve run into the issue before and to see if they can provide a fix.
Ya, unfortunately there are two rate limiting processes going on (one in jabberd and one in AOL) and the sending and receipt of rosters and presence between AOL and jabberd is entirely server-driven (beyond the initial trigger you give it via the client-server protocol). As long as you are running a small community, it’'s worth it to pursue solutions through AIM-T modifications/fixes.
If you run a larger community, you should be aware that AIM transports aren’'t going to scale and once you pass a certain threshold, AIM will actively block your transport. At least for now, a client-side solution seems to be the only large scale solution for multi-protocol IM clients (ala Trillian).
I do hope you can get the server transport to work!