On 9 May 2006, at 18:31, Frederic Soulier wrote:
On Tue, 2006-05-09 at 11:19 +0900, Trustin Lee wrote:
On 5/9/06, Frederic Soulier <[EMAIL PROTECTED]> wrote:
Ok so I can achieve what I think the Demuxing stuff was doing by
having 2 ProtocolCodecFactory registered in the filter chain.
"codec1"
ProtocolCodecFactory_1
encoder1
decoder1
"codec2"
ProtocolCodecFactory_2
encoder2
decoder2
builder.addFirst("filter1", new ProtocolCodecFilter(codec1));
builder.addLast("filter2", new ProtocolCodecFilter(codec2));
In that case:
decoder1 writes to ProtocolDecoderOutput -> decoder2
encoder1 writes to ProtocolEncoderOutput -> encoder2
or is it symetrical?
decoder1 writes to ProtocolDecoderOutput -> decoder2
encoder2 writes to ProtocolEncoderOutput -> encoder1
Is that correct?
Encoding is done exactly in the reversed order. So the latter is the
correct answer. :)
The one thing you have to note is that decoders will bypass non-
ByteBuffers,
and encoders will bypass ByteBuffers by its nature.
Thx Trustin.
I know it's been re-hashed to death but I'd like to clarify some
stuff :) I also went through the archives which prompted even more
question marks (lol).
"codec1" (ProtocolCodecFactory_1)
decoder1
encoder1
"codec2" (ProtocolCodecFactory_2)
decoder2
encoder2
"codec3" (ProtocolCodecFactory_3)
decoder3
encoder3
builder.addFirst("filter1", new ProtocolCodecFilter(codec1));
builder.addAfter("filter1", "filter2", new ProtocolCodecFilter
(codec2));
builder.addLast("filter3", new ProtocolCodecFilter(codec3));
So in that configuration, I have in order:
decoder1 -> decoder2 -> decoder3 -> IoHandler
encoder3 -> encoder2 -> encoder1
(Decoders)
In order for the chain of decoders to be executed properly decoder1
must
feed a ByteBuffer to decoder2 which must feed a ByteBuffer to decoder3
which can write anything; it will end up in messageReceived if the
IoHandler.
If decoder1 doesn't write a ByteBuffer then decoder2 and decoder3 are
completely bypassed and whatever decoder1 wrote on
ProtocolDecoderOutput
ends up in the messageReceived of the IoHandler.
Am I right so far?
When moving from one decoder to the next one I'm planning to
allocate a
new ByteBuffer and pass it onto the next decoder.
decoder1
- do something with incoming ByteBuffer
- allocate new ByteBuffer and copy whatever I need
- write ByteBuffer to out and move onto decoder2
decoder2
- do something with incoming ByteBuffer
- allocate new ByteBuffer and copy whatever I need
- write ByteBuffer to out and move onto decoder3
decoder3
- do something with incoming ByteBuffer
- allocate new ByteBuffer and copy whatever I need
- write <something> that ends up in the IoHandler
messageReceived() method
(Encoders)
If I write a message (Object) using the IoSession.write(Object) method
then encoder3 receives the message. Right?
If I write a ByteBuffer using the IoSession.write(Object) method then
the whole chain of encoders is bypassed. Right?
If I write a message (Object) using the IoSession.write(Object) method
then encoder3 receives the message. Now I can only write a ByteBuffer
using ProtocolEncoderOutput.write(ByteBuffer) so isn't that going to
bypass the remaining encoders?
I don't understand how to chain the encoders.
Note that I have all this working fine with just 1 decoder and 1
encoder
but we'd like to take a layered approach to decode/encode our message
protocol hence the above.
Just replying to myself to say that what I wrote earlier is a pile of
non-sense... Duh!
I can't have more than 1 ProtocolCodecFilter in the filter chain for
a start (should have read a reply from peter royal more carefully...)
So I'm going to try with 1 ProtocolCodecFilter and a bunch of
IoFilters to obtain something like:
builder.addFirst("codecFilter", new ProtocolCodecFilter(codec));
builder.addLast("myfilter1", new MyFilter1());
builder.addLast("myfilter2", new MyFilter2());
client to server:
decoder1 (decode)
-> myfilter1 (messageReceived)
-> myfilter2 (messageReceived)
-> IoHandler (messageReceived)
server to client:
IoSession.write(Object)
myfilter2 (messageSent)
-> myfilter1 (messageSent)
-> encoder1 (encode)
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
