[
https://issues.apache.org/jira/browse/DIRMINA-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833888#action_12833888
]
Victor N commented on DIRMINA-764:
----------------------------------
>> a malevolent client can kill a mina server in a matter of seconds. This has
>> to be fixed. <<
In fact, this is not mina-specific problem, this is more common in network
world. But I agree, we should propose some solutions, ex.:
1) writeRequestQueue may be bounded - somewhere we could configure its size and
a policy "what to do when the queue is full" (like in Executors)
2) some kind of write throttling (optionally) - as I remember, mina already has
IoEventQueueThrottle class, but I never used it and I do not know if it is
up-to-date
If some client (an IoSession) is slow, that is there are many events waiting
for socket write, it is server application's responsibility to decide what to
do - ignore new events, send some kind of warning to client ("hay, mister, you
network is too slow, you risk to be disconnected!"), maybe event client
disconnection after some time, etc. If client and server can negotiate in this
situation, everything will work well. We did something like this for Flash
clients using Red5 server (based on mina) - we checked writeRequestQueue (or
calculated the number or pending write request, maybe) and tuned frame rate of
video stream; sometimes we sent a warning to client :)
Of course, there may be"bad clients" trying to do DDOS - this way we can also
handle such situations.
> DDOS possible in only a few seconds...
> --------------------------------------
>
> Key: DIRMINA-764
> URL: https://issues.apache.org/jira/browse/DIRMINA-764
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.0-RC1
> Reporter: Emmanuel Lecharny
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> We can kill a server in just a few seconds using the stress test found in
> DIRMINA-762.
> If we inject messages with no delay, using 50 threads to do that, the
> ProtocolCodecFilter$MessageWriteRequest is stuffed with hundred of thousands
> messages waiting to be written back to the client, with no success.
> On the client side, we receive almost no messages :
> 0 messages/sec (total messages received 1)
> 2 messages/sec (total messages received 11)
> 8 messages/sec (total messages received 55)
> 8 messages/sec (total messages received 95)
> 9 messages/sec (total messages received 144)
> 3 messages/sec (total messages received 162)
> 1 messages/sec (total messages received 169)
> ...
> On the server side, the memory is totally swamped in 20 seconds, with no way
> to recover :
> Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: Java heap
> space
> (see graph attached)
> On the server, ConcurrentLinkedQueue contain the messages to be written (in
> my case, 724 499 Node are present). There are also 361629
> DefaultWriteRequests, 361628 DefaultWriteFutures, 361625 SimpleBuffer, 361
> 618 ProtocolCodecFilter$MessageWriteRequest and 361 614
> ProtocolCodecFilter$EncodedWriteRequests.
> That mean we don't flush them to the client at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
