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
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
>
