Re: [Dpp-devel] XMPP chat flooding?

[Andreas H. <haf...@in...>]

Hi guys,

to my mail below to jd...@ja... I got one response from someone 
called Rene Treffer. He gave me a couple of pointers.

1. The limit for sending messages is server dependant. He said that 
normally the limit is at sth like 100 per second, and 10-20 per second 
should always be fine.

2. We should look into stream management, esp. this part: 
http://xmpp.org/extensions/xep-0198.html#throttling . When a client 
sends too many messages to the server, the server *can* send a 
notification if the client was throttled, which *can* also contain the 
max number of messages without ack. So for XMPP we would need to be able 
to count the number of messages we sent without receiving an ack from 
the server. I have no idea whether we already do this or not.

3. If we do get throttled, the server is allowed to silently drop 
packages (implementation specific). But I guess that's where the 
consistency watchdog comes in, so we should be fine.

4. In case we get kicked, the XMPP core spec says that we should wait 
increasingly longer between reconnection attempts. I don't think we do 
this right now, AFAIK we always use the same interval. Also the 
reconnection attempts happen in the UI layer, not the network layer.

5. We might want to look into publish-subscribe. 
http://xmpp.org/extensions/xep-0060.html Especially when there's more 
than two clients in a session this seems like a good idea. I don't know 
if it's worth the trouble though, probably not.

So right now we should be fine, we might even lower the default interval 
between messages to 200 or even 100ms. Being able to handle throttling 
notifications from the server sounds like a Good Thing though.

Best regards
Andreas




On 12/13/2010 1:20 PM, Andreas Haferburg wrote:
> Hello,
>
> for the Saros project [1] we use XMPP chat for communication (using
> Smack). Saros is an Eclipse plugin, providing distributed editing
> functionality: When one session participant edits a shared document, we
> use XMPP chat messages to replicate these changes in the editors of all
> the other session participants.
>
> Currently we only send one message (XML stanza, right?) per second to
> each participant (typically only one other person, but occasionally
> 2-4). However, this means that there's a delay of up to 1000ms between a
> change and its replication.
>
> Ideally, we would like to achieve the replication in as close to
> real-time as possible. According to [2], point 7, the number of "XML
> stanzas that a server will accept over a given TCP connection or for a
> given JabberID in a given time period" could be limited. We would like
> to know how we should handle that. Exactly how much is too much here?
>
> Is there any way to request information about what we're allowed to do?
> What exactly happens if we're doing something forbidden, do we get
> disconnected? Banned? (Can we reconnect immediately?) Is there a
> specific error message (or warning)?
>
> Thank you very much
> Andreas
>
> [1] http://www.saros-project.org/
> [2] http://xmpp.org/extensions/xep-0205.html#solutions
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Dpp-devel mailing list
> Dpp...@li...
> https://lists.sourceforge.net/lists/listinfo/dpp-devel


-- 
Andreas