powered by Jive Software

Flood protection?

Today one of our co-workers tried to flood other user’‘s client with hundreds of simleys. But his client crashed instead. So i’'m wondering, is there some flood protection in Wildfire? Or maybe you can add some option to limit message size (char count) to prevent any server overloading from client side?

Anyone else interested in this? Maybe such option could be incorporated in Content Filter plugin? Repeating of same chars, maybe chars limit per message.

this actually would be a good idea, cause this can lead into protecting the system and other users from users who are spreading viruses through file transfer.

A good baseball bat can do wonders when trying to prevent things like this.

I would like to suggest JEP-0176 Baseball Bat To The Cranium.

Hi wroot (:

how should a server-side flood protection work? May be very hard to implement, limiting the message or packet size should be easy to implement without much overhead. Maybe the content filter could be modified to do this.

Limiting the amount of messages per second or the bandwidth used could be much harder to implement unless every user uses a 9200 kbit modem to connect.


Well, it was just a thought. Maybe thre is not much use for a server. But i just wonder if i can prevent users from distracting others with flood messages. Though maybe filtering of such thing will make CPU very high and slow down server anyway.

Hey wroot,

if you only use jive in in-corporation that may limit message size in client.maybe client message maxnium size in 5000 charact is enough.


Yes, this could be one of possibilities. Exodus (which we use) doesnt have such limit.

5000 chars?? I would limit it to 100 per message Or maybe one message / 5 secs.

Hi Oleg,

100 chars per message are 33 emotions. This should be enough to crash Spark with only a few messages. Disabling emotions (or max. five emotions displayed as image per minute) should help much more. I assume you already saw my OOM post in the Spark forum.


I find character limits annoying. If this is introduced, please make it configurable.

We are not developers, so dont worry yet If ever implemented this should be a plugin, and configurable of course

Hey wroot,

if you use exodus,i suggest you find a dephi book to study and complie it,you will easy control character size,hopfully you can do it.


Yeah Maybe sometime, in my spare time. I’'m already N-in-1, to be a programmer is last what left, heh. But thanks for suggestion

Hey Wroot,

The commerical XMPP server we used to use prior to moving to Wildfire had the concept of karma, where if a user started flooding the server with traffic their messages would receive a lower routing/delivery priority. It’‘s been awhile so I don’‘t remember if the karma was effected by number and/or size messages but I thought it was an interesting idea, even if it never kicked in. As LG said, doing this sort of thing with a plugin probably wouldn’'t be possible but it might be a nice feature to implement sometime in the future.



Wow. Karma. Sounds interesting. And if you are not speaking your karma is getting better?

Well, let’'s just dont invent something too complex for such simple thing, in fact. Maybe some simple limit of chars, messages, emoticons per minute etc, to start.

BTW, i’'m really thankful for all your suggestions and thoughts here. Dont have many points to give though

Not directly related, but close, is the idea of using content filtering to do some sort of spam/virus filtering. You could do bayisan statistics (like most spam filters do now) to determine of a message is worthy of delivery. Same with virus filterings.

And every message trailed with (This message was scanned by AVG, no virus found) Just joking

Hi wroot,

marking a third answer as helpful is possible without problems, and spending points is absolutely no problem.


As more join our server, I’'m finding the same issue as people posting log files to gain help from others only to lag the system to the point of stall. So a line limit would be a very nice feature to have. Hope this moves to a higher priority of implementation.