Custom channel identifier alternative

[Frederic Bregier]

Hi,

>From my point of view, I think that whatever the framework you use (except
the one you use before it seems), this problem should be a "business"
problem, not a "network" problem.
What I mean, is that if you have a special Id for one client (let say your
mobile device), probably you have to send as the very first message this id,
such that the connection will be linked to this special Id (or relinked if
the previous channel was over). Probably your previous framework was doing
this under the wood and you just don't know it ?
So yes, Netty cannot do that for you, or it would be magic ;-) This has to
be taken by the business logic, using of course the network framework
capacity.

For me, if I had to do something like that, I will do as the following
(probably not optimal, but this is my first though):

1) having a concurrent map that stores with index this SpecialId an object
that includes at least the current channel.
2) having a handler (the last one in the pipeline) that is stateful so
unique by channel (using a ChannelPipelineFactory), probably of the form of
SimpleChannelHandler
3) probably insert a OrderedMemoryAwareThreadPoolExecutor in the pipeline
(generally just after the codec but must be before the business handler), in
order to keep message in order for one channel
3) on messageReceived first call (a volatile boolean can do the trick), the
message must be the specialId of the client (mobile device); then check in
the map if this id is referenced, if so, close the previous channel and
replace the channel with the new one ; of course store this specialId in a
variable of the handler (so again my second option of my previous post)
4) on other messageReceived or any operations that need this specialId, just
use it from your handler
5) on channelClosed, check if the specialId is linked with the closed
channel (be careful that this closing can be due to a replacement, so that
you do not close the "new" valid channel)

On client side, when it connects, it should just send the specialId as very
first message and that's it.

I really think that if your previous framework was giving you this
specialId, it was doing something close to that. If not, as you said the IP
can change, how can it get back the correct connection with the correct id
without beeing sent by the client itself when reconnection occurs ? 
Maybe I'm missing something (I think your framework does not used something
like MacAddess) ?

OK, probably this is not so simple, but I think it is not too far of your
need (at least, for what I've understood). Hope this helps ;-)

Frederic


fatzopilot wrote:
> 
> Hi,
> 
> Frederic, first of all, thanks for your suggestions.
> I use a somewhat unrealiable connection (mobile), and sometimes there is a
> timeout at the client side which the server does not notice. The client
> then tries to reconnect (sometimes even with a different IP) but the
> former channel stays open. I don't know however, if this is a general
> charachteristic of socket connections or if it is specific to the former
> socket framework I used (and won't happen with Netty therefor).
> So, what I need when a new channel is established is to check (using the
> unique client ID) if my client has already connected to a different
> channel, and if so, get this channel and close it. 
> I do not see this is possible with the ChannelLocal or channel handler
> attribute or am I wrong?
> Are there other options? 
> 
> Thank
> fatzopilot
> 


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/Custom-channel-identifier-alternative-tp3326889p3329308.html
Sent from the Netty User Group mailing list archive at Nabble.com.