Custom channel identifier alternative

[Frederic Bregier]

Hi,

I will try to answer to some of your questions...

For the OrderedMemoryAwareThreadPoolExecutor, if order of your messages from
the client has no value for your business (such that message 2 can be
answered before message 1 for instance), then you don't have to have such
executor in your pipeline. Most of the time, when a client have a stateful
session, we have to have this order respected, so my suggestion. If not for
you, just forget it. For more information, please tale a look into the API.

For the reference to the map, I would say that you have to create a "global"
map that is accessible to all channels. A static object may do the trick for
simplicity or any other way such as creating this map at the very start of
your server and then pass it as a constructor argument to the
pipelineFactory that will include it into each new business handler as a
constructor argument too.

The way you prefer is depending on your project, if you like or not static
object or if you prefer to have dynamic object...

The extra codes you need is somehow small (a map, a boolean to see if the
connection is already initialized, and the getter ans setter for the special
Id into messageReceived and channelClosed, those closing the current or
previous channel if any). You already have the id in each message, so this
is already done. I don't feel it like a huge amount of work.

Now for your proposition, I think Trustin (when he comes back of holidays
;-) or others committers could answer your question more precisely. My
opinion would be the following (note that is only my opinion):

- having a map that returns an object from a channel Id is already done in
ChannelLocal

- so maybe the need could be a map returning a channel from an object,
assuming that this object is a unique identifier specified by the business:
I feel like it is business dependent (the necessary functions of comparison
between keys is completely implementation dependent with regards on the key
itself). However perhaps it is possible to have at least a sequeleton of
this in Netty (that is what you are going to write anyway).

- changing the channel Id (or adding another one) could be more tricky and
not error prone: this id should be unique (at least during the life of the
channel), so as the new id sets by the user. If I take your example, what
could be the logic then when one client reconnects with a new channel
whereas in the same time the previous channel is still active? You cannot
have two channels with the same Id, right? So you have to close one: which
one? I would say this kind of implementation is quite business dependent too
(at least the decision on which one to close). 
For the moment I cannot see an implementation that would fit any usage...
but perhaps other people (including you of course) could specify more this
kind of things to see how to implement it if this is useful.
We can imagine different behaviors when this id is set and there is another
channel already registered with the same id: any previously channel is
closed; the new channel is refused; some competitions between them must be
done (like is the previous one still responding and active or no more
responsive); ...
Also setting this id is obviously done when the new channel is already
connected and probably when a message is received with this special id in
the message, so the setting must be controled by the programmer and cannot
be automatic, which could lead to issues (imagine the worst case where the
same client just opens two channels almost in the same time, which one is
correct?).

Anyway, that's an interesting question!

HTH,
Frederic


fatzopilot wrote:
> 
> 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
> 


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