On Tue, Jan 26, 2010 at 7:22 PM, XuQing Tan <[email protected]> wrote: > Hi, Ashish > > thanks for your reply > >>I doubt you would need any time out stuff, unless I am missing something.. > > OK, as it is an endless loop if the package/frame not received completely, > the session is block and the corresponding thread resource not released for > ever. > then let's imaging following two scenarios: > 1. if it's a persist connection, and the client occasionally send a > im-complete frame first, then this session on the server side is blocked, > even then the client send a second complete frame to server > 2. if it's not a persist connection, and there are a lot of clients send > request to the server, some clients for unknown reason, send a lot of > im-complete frames to the server, which cause a lot of thread busy polling > the im-complete frame (and never be completed) on the server side, if there > are too many this kind bad clients, the server could be suck soon as it > cannot service any more request, is it some kind of DoS (Denial of Service)? > > although I know that my assumption are all based on "it is a bad client", > but I want to try to avoid scenarios above
If a session is idle, an event is generated. You can choose to cleanup there. I don't remember, but think if a session is Idle it's closed. To block unknown clients, use blacklist filter :-) > is it reasonable? > > thanks again > > > Thanks & Best Regards! > > /// > (. .) > --------ooO--(_)--Ooo-------- > | Nick Tan | > ----------------------------- > > > > On Tue, Jan 26, 2010 at 6:55 PM, Ashish <[email protected]> wrote: > >> On Tue, Jan 26, 2010 at 3:19 PM, XuQing Tan <[email protected]> wrote: >> > Hi, mina guys >> > >> > first, MINA is a very nice framework, very easy to use, and another much >> > more inspiring thing is the community is much more active recently and >> the >> > MINA 3.0 is on the way >> > >> > here I have a question about implement protocol codec on server side by >> > extending CumulativeProtocolDecoder, I try the examples first which saved >> me >> > a lot of time >> > but I notice that there's no way to support timeout in >> > CumulativeProtocolDecoder >> > >> > since socket is stream based, and CumulativeProtocolDecoder is to help >> recv >> > the integrity request data, if the data is not recv completed, return >> > <code>false</code> in doDecode to tell the CumulativeProtocolDecoder more >> > data is needed, if the additional data not recv, it is a infinite loop, >> > right? (according to the code in >> > *org.apache.mina.filter.codec.CumulativeProtocolDecoder.decode(IoSession, >> > IoBuffer, ProtocolDecoderOutput)*) >> > >> > so, that session blocked, and even more, other client new request are >> > blocked too? >> > I think it relatively easy to implement a "retry-time' strategy to >> prevent >> > from this suck, by attach a re-try time count as attribute to the session >> > but after all, it is not a time out >> >> you got things correctly, its just that each client shall have its own >> session and an instance of Filter working for each session. >> So essentially, you Filter/Decoder processes messages from a single >> client. No other Client requests are blocked. >> >> > so is there any other ways to provide the read timeout mechanism, have I >> > missed any thing? >> >> I doubt you would need any time out stuff, unless I am missing something.. >> >> > Thanks in advanced >> > >> > Thanks & Best Regards! >> > >> > /// >> > (. .) >> > --------ooO--(_)--Ooo-------- >> > | Nick Tan | >> > ----------------------------- >> > >> >> >> >> -- >> thanks >> ashish >> >> Blog: http://www.ashishpaliwal.com/blog >> My Photo Galleries: http://www.pbase.com/ashishpaliwal >> > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
