only allowing one connection per IP address

[Frederic Bregier]

Hi Trustin,

I change to ChannelFutureListener.CLOSE. I was too quick on this and
even don't see this possibility (faster and better).

On IPV6, it will take me some times, specially since I'm not a network guy
so IPV6 is quite "new" for me. I will take some info (hippi wikipedia! ;-)
and will return with some proposal for this.
In the meantime, if someone has a way to support IPV6 either in IpSubnet
or in a seperate class implementing IpFilterRule, it will be ok 
(as the IpFilterRuleHandler use an interface of IpFilterRule, IpSubnet is not
mandatory).

Now on the main problem, I fully agree and understand from the first entry
your point, and I try to find the best way to try to answer to it.
However, as you see, there is a pitfall. Le me resume it:
- Since we cannot assume that OPEN or BOUND give us the remote InetAddress,
  we can not block (filter) those channels at that point.

- We can only block them from CONNECTED event where we can have access to InetAddress.

- Then we can block every new events, up to CLOSE itself.

- We could block everything except UNBOUND and CLOSED, to be symmetric.
  But then we need to focus on special handler that might need to do something before
  closing. One example is the OneIpFilterHandler where it adds a new remote address
  at CONNECTED if allowed, and removes it at CLOSED.
  Perhaps, we can move this removing code to the DISCONNECTED event to be symmetric
  and let the UNBOUND and CLOSED events continues.

- I feel unconfortable with isBlocked method that a user might want to change since
  it is used for instance in OneIpFilter to test the removal. So it is quite dangerous
  to change this. So I propose to change a bit the logic, see below.

- Now on UNBOUND and CLOSED events, one might want to block them silently (like me).
  I could propose two possibilities:

  1) For all events, a new method continue() will be called if the channel was blocked
    and if it answears true, then the event has to continue. Else the event stop
    as it should be (whatever the event is, but starting from CONNECTED event only).
    So the user has the possibility to check what kind of event it is (argument)
    and to decide if the event should continue or not. If by default, no event has to
    continue, then the user has no need to take care of it (always return false).

  2) Or simpler as of coding but not perhaps for end user, overridden the main method
    handleUpstream, removing any blocking events from the handlers and let the user
    assume what he wants to do.
    I feel unconfortable with this approach since most of the time, end user might
    want to block everything...

    A sub solution, might be to not block at all only UNBOUND and CLOSED events?
    WDYT?

I've made some changes according to my ideas. Could you see if it is better?

Cheers,

Frederic



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