Custom channel identifier alternative

[fatzopilot]

Hi Frederic,

> 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).
Indeed, this is, what my clients do.  They sent their client ID in every
message.

> 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
Hm, I do not see whether this is necessary in my case. Do you think this is
really needed?

> 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)
OK, from where do I get a reference to the map? What would be the best
approach to do this?

> 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)
This is reasonable. In fact, I was doing very similar stuff with the old
framework.
The difference was, that I could just rename the channelID, and then could
use a channelGroup to find out whether a specific client already logged in
and get the corresponding channel.
That saved me from doing the stuff I have to do now (additional map and
introduction of channel attribute.)

> I really think that if your previous framework was giving you this
> specialId, it was doing something
> lose to that. If not, as you said the IP can change, how can it get back
> the correct connection with 
> the correct id without being sent by the client itself when reconnection
> occurs ? 
Well, the business logic is responsible for closing orphaned channels. But
it has to get the previously used channel somehow of course.
> Maybe I'm missing something (I think your framework does not used
> something like MacAddess) ?
No, no MACs involved.
> 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 ;-)
Yepp, thank you very much.
> Frederic

Anyway, if somebody has other ideas I would really appreciate them.
In addition, I propose to consider something like an optional identifier (in
addition to the ID assigned  by the framework) which can be used to obtain a
channel from a channel group, or the possibility to change the channel ID.

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