On 5/28/10 1:56 PM, dan brownell wrote:
Hi Emmanuel,
I'm using Mina 2.0, RC1.
Can you provide your decoder code ?
Well, I gave up on my own decoder because I saw PrefixedStringCodecFactory
already exists.
All I'm doing currently is adding it to the filter.
Right, sorry !
ProtocolCodecFactory factory = new PrefixedStringCodecFactory();
chain.addLast("codec", new ProtocolCodecFilter(factory));
The issue is that I will be sending the string from a C++ socket, so I can't
just use putPrefixedString(). When my test client uses the code I provided
before, (i.e., wr.write(myString.length()); wr.write(myString);) I get the
following at the INFO level, which is before any of my code in
messageReceived() runs. Obviously the dataLength is over the top.
INFO: RECEIVED: HeapBuffer[pos=0 lim=2048 cap=2048: 05 3C 3F 78 6D 6C 20 76 65
72 73 69 6F 6E 3D 27...]
org.apache.mina.filter.codec.ProtocolDecoderException:
org.apache.mina.core.buffer.BufferDataException: dataLength: 87834488 (Hexdump:
05 3C ...blah blah)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:235)
This suggests I am not emulating putPrefixedString correctly.
When using the PrefixedStringCodecFactor constructor without any
parameter, it assumes that the message's length will be encoded as an
int, ie on 4 bytes. The received data seems to show that it's not the
case, as 05 3C 3F 78 can't be either an int, nor 5 can be the length of
the following string ("<?xml version='...").
I suggest first that you use a CumulativeProtocolDecoder to handle your
length-value messages , as it's shown in the ImageRequestDecoder class
(in mina-example, imagine sample). (It seems that the PrfixedString
codec might not handle correctly split messages (nit 100% sure, to be
checked).
Also try to check that the wr.write(length) really write 4 butes, not
only one. Also check that the bytes ordering are compatible as you write
them using C - you may have big-indian/little-indian issues)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
