Hi Trustin
Thx for your answer. It makes sense.
In our case UDP messages from clients are guaranteed to fit in 1 UDP
packet therefore the fact that UDP packet #2 may arrive before UDP
packet #1 is not relevant. At our level we just get message #2 before
message #1 and they are completely independant.
Obviously should the need arise to have larger messages from the
client we'll have to reconstruct the messages using UDP packets in
the right order.
The 2nd interesting finding which is more disconcerting is that using
MINA 1.1.3 there's effectively no accumulation by the
CumulativeProtocolDecoder for UDP traffic.
We skipped MINA 1.1.4 because of an issue with ProtocolCodecExection
I reported.
With MINA 1.1.5 the ProtocolCodecException works as per 1.1.3 but the
CumulativeProtocolDecoder now accumulates data for UDP!
Our app using 1.1.3 --> no accumulation for UDP
Our app using 1.1.4 --> accumulation for UDP
Could you confirm this change of behaviour?
On 13 Dec 2007, at 04:07, Trustin Lee wrote:
It's no use to use CumulativeProtocolDecoder in UDP because UDP never
guarantees the order of packets. Messages can be mixed up. :)
HTH,
Trustin
On Dec 12, 2007 4:27 AM, Frederic Soulier
<[EMAIL PROTECTED]> wrote:
Hi
I have an issue with Datagrams and the CumulativeProtocolDecoder
which doesn't seem to cumulate!
(working just fine with TCP).
I have a Decoder extending CumulativeProtocolDecoder.
protected boolean doDecode(IoSession session, ByteBuffer in,
ProtocolDecoderOutput out)
throws Exception
{
int startIndex = in.position(); // Save buffer position
boolean done = doDecodeWithoutBackingUp(session, in, out);
if (!done)
{
// Reset buffer to start as-if doDecodeWithoutBackingUp
had never run
in.position(startIndex);
}
return done;
}
protected boolean doDecodeWithoutBackingUp(IoSession ioSession,
ByteBuffer in, ProtocolDecoderOutput out)
throws Exception
{
if (in.remaining() < TYPE_SIZE)
{
return false; // Need more data, we don't have the type
of the message
}
else
{
type = in.get();
if (type == TYPE_MSG)
{
if (in.remaining() < TRANSACTION_ID_SIZE)
{
return false; // Need more data, we don't have
the transaction id
}
else
{
transactionId = in.getInt();
// do we have the message length?
if (in.remaining() <
CodecUtils.MESSAGE_LENGTH_SIZE)
{
return false; // Need more data, we
don't have
the message length
}
else
{
int dataLength = in.getInt(); // Read
4-byte
int data length
// do we have all the data?
if (in.remaining() < dataLength)
{
// Here we're already read 9
bytes (1 byte + 1 int + 1 int) but
==> // we don't have all we need so
we return false and next time
// around we'll have more
return false; // Need more data,
we don't have the complete data
}
else
{
** HERE WE PROCESS A FULL
MESSAGE **
return true; // Please carry
on giving
us more data to decode
}
}
}
}
else
{
throw new MySuperDuperException();
}
}
}
The buffer (in.remaining = 30)
I read 9 bytes from the buffer to be able to decide whether to read
more or not.
in.remaining = 20 but my data length is 50 so I need more bytes and
return false.
Another datagram is received in the meantime, I expect the new
datagram to be accumulated behind what I haven't processed
(considering I returned true).
Instead I only get the new datagram and the previous stuff I haven't
processed yet is gone to the big bit bucket in the sky!
Is the Cumulative stuff supposed to work with UDP the same way it
works with TCP? As I wrote at the top it works prefectly with TCP.
Thx.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
