One practical consequence for the XML stream is a separate <presence> Stanza is sent from the server to the client for each contact. I have To check the karma code to see if the client connection's karma is charged For this traffic.
500 contacts means 500 <presence> stanzas, each one being something like 150 bytes longs (payload, not including Ethernet, TCP and IP headers, call it 200 bytes in round numbers). So we get 5 contacts per 1kB on the Wire or 100kB, which is 800kb on the wire. Rather heavy duty. ;( But there Does not appear to be any choice at this time....so dribbling the presence Data out to the client over some time period appears to be desireable. I have to read the karma code understand the impact of traffic to a destination On the karma (possible DOS against a user here?) and compare the release code of jabberd-1.4.3 to the cvs code to understand jabberd-14's handling of this better. Jonathan -----Original Message----- From: Mickael Remond [mailto:[EMAIL PROTECTED] Sent: Thursday, December 09, 2004 5:05 AM To: Jabber software development list Cc: Bresler, Jonathan Subject: Re: [jdev] Presence packets bottleneck on huge rosters Bresler, Jonathan wrote: > Hello, > > Large roster lists on active servers with a number of users are a problem. > All the more so if the connections are encrypted. The current jabberd14 code > (reading, still have jabberd2 and ejabberd to read) sends out <presence> > Stanzas immediately. This can be intense. > > One easy to implement option, that might not twist the RFCs to hard, is to > schedule > The <presence> stanzas over some short time period using the heartbeats that > are > Available in jabberd14 (and presumeably jabberd2 and ejabberd). That was one of my thought. I did not know the heartbeat mechanism of Jabberd1.4. What are the practical consequences on the XML stream ? I mean for example, if you have 500 contacts in your roster, how would the server send the presence packets to the destination and how much time will it take ? Another of my thought was to use some kind of message delivery scheduler, that would rearrange priority between messages. For example, normal messages would be delivered with a higher priority than presence packet. The scheduler could also play the role of the heartbeat to regulate the number of presence packet sent over an interval of time. I did not yet thought of all the implication of this change. -- Micka�l R�mond http://www.erlang-projects.org/ --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.804 / Virus Database: 546 - Release Date: 11/30/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.804 / Virus Database: 546 - Release Date: 11/30/2004 _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
