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