Hi Martin,

sorry, I overlooked your mail, and replied too quickly (ie, before my
morning coffee)... I thought you were talking about both sides (client
*and* server).


So et's go back to your initial question :

Actually, the ProtocolcodecFilter just get IoBuffer as an input :


    public void messageReceived(NextFilter nextFilter, IoSession
session, Object message) throws Exception {
        LOGGER.debug("Processing a MESSAGE_RECEIVED for session {}",
session.getId());

        if (!(message instanceof IoBuffer)) {
            nextFilter.messageReceived(session, message);
            return;
        }

which means if you have already decoded your message and produced a data
structure that is not stored in a IOBuffer, the second instance wont be
called.


So if your WebSocket codec does more than extract data and put them in a
IoBuffer, then yes, your binary codec won't be called. In this case, you
have little choice but designing a Filter that mimic the
ProtocolCodecFilter, but with a different messageReceived() method that
does not pass the message to the next filter.


You can also implement both codec in one single filter, but it's a bit
more ugly, mixing concepts...


Hope it helps !



Le 13/07/2017 à 10:33, Martin Asenov a écrit :
> hi, Emmanuel,
> I don't really understand your proposal. The code I posted is just on the
> server side. The client is Unity-based game.
> How do I actually rearrange things to achieve that?
>
> Thanks,
>
> On 13 July 2017 at 07:33, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>
>>
>> Le 12/07/2017 à 20:00, Martin Asenov a écrit :
>>> When creating my Mina Server, I specify this:
>>>
>>>     this.acceptor = new NioSocketAcceptor();
>>>
>>>     this.acceptor.getFilterChain().addLast("logger", new
>> LoggingFilter());
>>>     this.acceptor.getFilterChain().addLast("webSocketCodec", new
>>> ProtocolCodecFilter(new WebSocketCodecFactory()));
>>>     this.acceptor.getFilterChain().addLast("binaryCodec", new
>>> ProtocolCodecFilter(new DefaultCodecFactory()));
>>>
>>> The webSocketCodec is one that handles WebSocket handshake stuff. The
>>> binaryCodec is the one that parses custom binary protocol messages.
>>>
>>> In this setup, I expect the following:
>>>
>>> client sends data -> webSocketCodec.encode -> binaryCodec.encode
>>> server writes data -> binaryCodec.encode -> webSocketCodec.encode
>>>
>>> Unfortunately, only the first step of each flow is called. What am I
>> doing
>>> wrong? Can't I use to Protocol Codec Filters after each other?
>> You can, but you have to add the codecs in the rigth order : on the
>> server side, the binary codec has to be stacked *before* the
>> websocketcodec.O the client, it's the opposite.
>>
>> --
>> Emmanuel Lecharny
>>
>> Symas.com
>> directory.apache.org
>>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Reply via email to