only allowing one connection per IP address

Frederic Bregier fredbregier at free.fr
Mon Mar 23 06:36:56 EDT 2009


Hi Trustin,

I come back on some points. Mainly the core of IpFilteringHandler

>> * for handleRefusedChannel(), did you mean that any actions 
>> other than closing could be done here? Or say in another way, 
>> closing is still outside of this method in order to be factorized 
>> whatever the action (or no action) is done in the method ? 
>I mean even the close request should be done in 
>handlerRefusedChannel() and therefore its default implementation 
>should be: 
>
>    protected void handleRefusedChannel(ctx, evt) { 
>        ctx.getChannel().close(); 
>    } 

>and a user could override this method if necessary. 

I feel a bit different. I implement in fact three methods:
- channelConnectedAccept : this one is called from the handleUpstream (CONNECT event).
    It first calls accept, then if true, it calls handleRefusedChannel 

- accept : this one has to be given by the implementation (ex IpBlackWhiteList)

- handleRefusedChannel : this one has to be given by the implementation and by default do nothing

My idea is that any implementation has not to re-write or call super() if possible in order to handle the steps accept then handleRefused then close.
And my argument (but of course I could be wrong, so my proposal) is that when the close signal is on going, the fourth method channelClosedContinue (another name could be better) is called and can block the chain in the pipeline.
Of course, why doing that ?
I feel, (I may be wrong), that when a connection is refused, it should not go to the next entry in the pipeline but stop as early as possible. Of course, if one wants however to continue, he can call in handleRefused the next entry in the pipeline by itself, and the same he can rewrite channelClosedContinue in order to return always false (so goes to the next entry for CLOSED event too).

That's was one of the reason I was thinking to block as early as possible (if wanted) the connection (from OPEN or BOUND). 
But as you said sometimes there could be no remoteAddress for sure, it is a bad idea.
However, what I would like is to prevent any message or whatever except connect and closed to be passed through.
Because I feel like this kind of handler should block as much as possible when the connection is clearly indentified as a bad one.

Again I may be wrong, and I understand that we are not completely on the same line. WDYT?

> * I don't think we need this many *Accept() methods.  My initial idea 
> was just to make IpFilterHandler to monitor all events so that any 
> connections can be closed even when messageReceived event is 
> triggered.  It could be like this: 
>
>     public void handlerUpstream(ctx, evt) { 
>         if (accept(..., ctx.getChannel().getRemoteAddress())) { 
>             ctx.sendUpstream(evt); 
>         } else { 
>             handleRefusedChannel(...); 
>         } 
>     } 

I understand your point. However, it seems we are not on the same base.
Of course, your point is more general than mine, I fully agree.
But I can't imagine (perhaps because still a bit sick) :( 
a situation where you want to block something after the connexion was done.
And moreover, you will call this accept method on every event, which could be not efficient
(depending of course on the implementation of the accept method).
However, with my proposal I've got a value already computed (attachment) that can enable blocking all event to be passed to the next entry in the pipeline. Is it ok for you this way ?


Another subject is IpSubnet. I feel like it could be as complete as possible.
Currently, it implements both CIDR and Subet. 
About IpRangeRule, what exactly do you mean? 
I cannot see right now what is the exact meaning of 192.168.0.0-128 .
Once understand, I can find a way to propose at least an interface, or a unique class that could implement all three.

My proposal is to have both black and white lists at the same time,
so enabling the user to have only one filter that handle all connections.
Of course, one can have two handlers in its implementation, letting one list empty (for instance first white list is empty then in the second this would be the black list).

Cheers,
Frederic
PS: excuse me if I am not clear or quick in understanding your points, probably due to my personal condition...

-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/only-allowing-one-connection-per-IP-address-tp2495797p2520369.html
Sent from the Netty User Group mailing list archive at Nabble.com.




More information about the netty-users mailing list