mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@archean.fr>
Subject Re: ConnectionThrottleFilter
Date Fri, 07 Nov 2008 10:07:35 GMT
Well it's documented and easy to understand, there is probably more
ugly code to cut, this one isn't hurting much :)

On Thu, 6 Nov 2008
17:13:01 -0500 "Mark Webb" <elihusmails@gmail.com> wrote:

> I am not currently using this for anything, I am sure that given
> enough time I could come up with reasons for using it.  OTOH, if we
> are looking to streamline the baseline, I say remove it and maybe
> create a filter repository that people can get to for  additional
> filters.  Something similar to what Apache has done with its modules.
> 
> --Mark
> 
> On Thu, Nov 6, 2008 at 3:58 PM, Emmanuel Lecharny
> <elecharny@gmail.com> wrote:
> > Niklas Gustavsson wrote:
> >>
> >> On Thu, Nov 6, 2008 at 6:46 PM, Julien Vermillard
> >> <jvermillard@archean.fr> wrote:
> >>
> >>>
> >>> But if you accept the session (opening) you send all the TCP soup
> >>> for opening/accepting the socket connection, and if you close the
> >>> session directly you send all the TCP soup for closing the socket
> >>> connection. I hardly can imagine it can protect you from any DoS.
> >>>
> >>
> >> That would at least be cheaper than doing the rest of your stuff
> >> (decoding/encoding, bussines logic and so on) , right?
> >
> > Well, if you are going to drop connections just because you have
> > hundred (or even thousands) arriving at the same time, then that
> > means your server is being badly DoSed. Now you have two cases :
> > - your server is reachable by outsiders : you better have a front
> > system to deal with such attacks. Whatever you do on MINA side will
> > be far from enough to protect you. So I tend to think that, in this
> > case, the connection throttling is absolutely useless.
> > - your server is only used from a private nertwork. Some wrong
> > process is pounding your server, and it will make it dies sooner or
> > later. Again, in this case, I would rather let it die quickly, in
> > order to be able to react quickly.
> >
> > Considering that such attacks (or incorrect usage from internal
> > applications) are impossible to avoid, trying to fix them on the
> > application layer is like trying to empty the sea with a tea
> > spoon...
> >
> >
> >> So while not
> >> the perfect protection, it is certainly better than nothing.
> >>
> >
> > well, in this very case, doing nothing or something is equivalent.
> > You are just offering a small margin during which your server will
> > resist, but I'm not sure it worth the effort.
> >
> > Of course, IMHO :)
> >
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel L├ęcharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >

Mime
View raw message