I have done that stuff, now it works like an IoAcceptor, and it works in this way:
On the "network-farm" side:
there is an IoHandler (called ForwarderHandler) that need to be connected to the thinking-block in some way ( by now with some Connector, but it can be done with an Acceptor too ).
After a "centralConnection" is opened ( the connection to the thinking-block), the ForwarderHandler will open the tcp ports required by the thinking block, and then it will forward all the events (receive, close, open, idle) of every new connection to the thinking block.
And this is all the story of the "network-farm" side.
On the "thinking-block" side:
I developed a IoAcceptor (called ForwarderAcceptor) that is a normal acceptor on wich you can do the bind() and unbind() methods, as usual, giving your own IoHandler (that I'll call GenericHandler) and setting your own filterChains ( I copyed all this stuff from SocketAcceptor ).
ForwarderAcceptor have to talk with the network-farm side, and it does this task with an IoHandler that works out the messages from and to the network-farm.
ForwarderAcceptor have a method that return the IoHandler I have just talked about, so you can do some little hack on it to do interesting thing, like a tree structure of network-farms ( I'll explain it better ).
ForwarderAcceptor receives the connections of the network-farm programs and receive from them the messages about the sessions handled.
And after all it forward this events to the GenericHandler, passing through the appropriate chains.
And this is the end of the implementation.
Some features:
both IoHandler (the ForwarderHandler and the ForwarderAcceptorHandler) use the same messages that are objects called ForwarderMessage.
Both them use ForwarderCodecFactory to translate messages into ByteBuffers.
In this way it is simple and performant to have a VmPipe connection between ForwarderAcceptor and ForwarderHandler, you have only to not use the codec at all.
By now it is not tested with more than one connection, and it do not provide compression of data or the methods "writeToAll" or "writeToSessionGroup", so by now it is just an "encapsuler", and by now it do not handle in the right way the ByteBuffer acquire and release, so it doesn't work in VmPipe mode because it throws IllegalStateExceptions, I have to work more on that.
It works on the lower level I can imagine, directly with ByteBuffers, so it can be used to forward every kind of protocol.
Well, this is more or less all the news I can give you about this stuff, I'm going to test it by my self with my applications, but I have to ask you something.
There are news about SessionGroup implementation? Because I need it to do the writeToAll methods, and I don't know how to manage the groups otherwise.
If somebody want to see the code I have written just ask me and I'll put it on jira, but it is just a stub right now.
