Multiplexing a client connection

[Frederic Bregier]

Hi Jony,

As far as I understand your questions, you have to face up several
differents problems.

A client bootstrap is somehow a shortcut to enable easier connection. So if
you use it to reconnect when the previous channel is over (closed), it is
just fine.

Now, to keep the reference of your "current" client channel (as it could
change), I would suggest you to store it in an object that would contain for
instance the bootstrap but also the last and current active channel. Doing
that, you will have to pass this object to each server channel, such that
you can write to the current and active client channel.

Now to replay the messages that weren't sent through the local client
channel, several ways (and other that I don't have in mind right now) can be
achieved (less simple):
- you can first test if the channel is still connected before writing. If so
just write, if not, re open the channel, replacing the previous one with the
new one. Take care to be "thread safe" there since it could be a minn
breaker (take care that if a problem occurs, only one thread will try to
reopen the channel and that other will wait this operation is ok to reuse
the result and to not close and reopen again a new one when not necessary).
This would be the most difficult operation. 
- Perhaps a more simpler way would be to only add this handling in
exceptionCaught and channelClosed of the client channel such that it only
occurs there. However, for write operation, you should add something to test
the channel is still connected or in reconnection process...
- you can also be blocking on the write operation (await), but keep
attention that you will have blocking operation, thus less efficiency. If
the operation is not in success, you know that you will have to send again
it through the new client channel.
- you can also add a listener on each write operation (much better than
await), a future listener on close or error, such that you will be informed
asynchronously that there was a problem, such that you can send again your
message. Note that the future listener will only inform you of the end of
the operation (and therefore the status) but you will have to create a new
future listener for each write such that in the constructor of this future
listener you can pass the message you wanted to write again in case of
error. Doing this way, I would suppose that you don't need to have a list of
messages since the future listeners will do that for you.

Well, I could say more, but I think this is a start, some ideas...
HTH,
Frederic


JonY wrote:
> 
> Hello Everyone,
> 
> I'm pretty new to netty, and I'm having a little trouble implementing a
> solution that I believe netty can handle. What I have so far is an
> application that contains a client bootstrap and a server bootstrap. The
> server accepts multiple connections and writes them to the client
> bootstrap's one persistent channel. The way I've done this is by passing
> the client bootstrap's channel to the server's handler and writing to it
> (I'm assuming there's a better/safer way to do this?). 
> 
> In addition to improving my current implementation, I need to be able to
> reconnect the client piece if the connection dies (i.e. unplugging the
> cable). I've tried reconnecting the channel in the client handler, but the
> channel sometimes gets closed even if the connection dies. I've also tried
> a number of other solutions involving trying to reconnect the bootstrap,
> etc from the exceptionCaught handler.
> 
> Given my current implementation, I need some way to reconnect the client
> bootstrap and then send the new channel to the server bootstrap. The
> server bootstrap then needs to start writing all of the data that has been
> queuing on the old channel to the new channel.
> 
> Any help/suggestions would be greatly appreciated!
> 
> Jon
> 


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/Multiplexing-a-client-connection-tp3347008p3348042.html
Sent from the Netty User Group mailing list archive at Nabble.com.