mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <nik...@trillian.se>
Subject Re: how to guarantee flushed write in encoder - mina-2.0.0-M1-snapshot
Date Thu, 04 Oct 2007 14:04:12 GMT
ubaggili wrote:
> Hello.
> I have spent a lot of time trying to figure out how I can write and flush
> "abc" through the ProtocolEncoderOutput but I have been unsuccessful.  I
> must be missing something too obvious as usual!
> In Mina 1.1.2, there was no issue with this.  I would be able to send off
> "abc" and "def" and they would get sent as 2 packets.  With Mina-2.0-m1, I'm
> unable to do so.  I have tried every trick and flip and flush, but I haven't
> been able to reliably solve this.  In some cases, the 2 messages are sent
> off separately but in as many others they are sent off as one packet.  I've
> even set the tcpnodelay property to false (which seems to be counter
> intuitive) but that wasn't it either.
> Any hints would be greatly appreciated.  Here is my sample code:
> public class AgiCommandEncoder implements MessageEncoder {
> ...
>     public void encode(IoSession session, Object message,
> ProtocolEncoderOutput out) throws Exception {
>         CommandRequest agiCommandRequest = (CommandRequest) message;
>         byte[] commandAsBytes = commandRequest.getCommand().getBytes();
>         IoBuffer buffer = IoBuffer.allocate(commandAsBytes.length, false); 
> //<==== IoBuffer is the new-old ByteBuffer in trunk
>         buffer.put(commandAsBytes);
>         buffer.flip();
>         out.write(buffer);
>     }
> ...
> }
> This encoder is registered as part of the DemuxingProtocolCodecFactory
> extended object.

I'm afraid I cannot answer how to achieve what you want. If your
protocol is TCP based I think it is dangerous to have a protocol which
is dependent on packet boundaries. AFAIK there is no way (at least not
in Java) to specify exactly what bytes should go in the same TCP packet.
If you are designing your own protocol you should consider introducing
some kind of boundary. That will make your protocol independent of how
the lower layers of the network stack decide to fragment the packets.


Niklas Therning

View raw message