You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@mina.apache.org by boB Gage <bg...@ekosystems.com> on 2008/12/29 21:50:54 UTC

Issue with VmPipeAddress

I've got a Mina application going that communicates with a variety of 
devices through both serial and network interfaces.

Part of this application is data-set simulations (ie fake far-end 
devices) handled by using VmPipeAddress and VmPipeConnector objects.

My data simulator puts data into the stream via session.write() calls; 
my "normal" decoders pick up that data as if it had come from a real device.

This set of objects works to an extent.   BUT....   data that is sent 
via two consecutive session.write() calls does NOT show up as expected 
in the decoder.

For example, assume a decoder that wants packets delimited by 0x01 
(start) and 0xFF (end)

   session.write(0x01 02 03 04 05)   followed by
   session.write(0x06 07 08 09 FF)

Generates two calls to "decode" in the decoder object.   

The first with five bytes 0x01 02 03 04 and 05 returns NEED_DATA because 
the 0xFF end is not seen
The second with 5 bytes 0x06 07 08 09 FF returns NOT_OK because there is 
no 0x01 start byte.

I would have expected two calls, but different parameters:
First with 0x01 02 03 04 05 which would return NEED_DATA.  
The second with 0x01 02 03 04 05 06 07 08 09 FF which would return OK 
(after parsing) because it had a full packet.


Am I suffering from unrealistic expectations??  Is this a known Mina 
bug???   Have I just done something stupid???


Thanks in advance,
boB

Re: Issue with VmPipeAddress

Posted by boB Gage <bg...@ekosystems.com>.

Thanks Maarten!

But that answer just confuses me more....

Our decoder tests have always arbitrarily chunked data into random-sized 
blocks before calling the Decoders' decode() method.    These tests have 
been working for quite some time. 

It is only the VmPipe connection (simulated data sets) that we are 
seeing this issue on (and if I trusted my memory half as much as my 
logic I'd swear this *used to* work -- maybe that changed when I 
upgraded to M2?).

Our Decoders have been MessageDecoders (descendants of 
MessageDecoderAdapter) that have been chained in via 
DemuxingProtocolCodecFactory-descendants calling their 
'addMessageDecoder()' one or more times to define a protocol.

Switching decoders to ProtocolDecoders (descended from 
CumulativeProtocolDecoder) means I can no longer use the same 
CodecFactory mechanisms, nor can I have multiple decoders (say for 
different packet types) within a single protocol.    Is this a necessary 
re-write that I should just get through now rather than later, or is 
there a better solution???

Each protocol is currently defined via:
   * One or more Decoders (extends MessageDecoderAdapter)
   * One or more Encoders (implements MessageEncoder<T>)
   * One Handler (extends IoHandlerAdapter)
   * One Codec Factory (extends DemuxingProtocolCodecFactory)

boB

Maarten Bosteels wrote:
> Hi boB,
>
> What you describe is the expected behaviour :-)
> You're decoder is notified whenever new data arrives.  Accumulating this
> data (when necessary) is the responsibility of the decoder.
>
> Usually the easiest thing to do is extending CumulativeProtocolDecoder.
>
> http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/codec/CumulativeProtocolDecoder.html
>
> Also have a look at
> http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html
>
> Maarten
>
>
> On Mon, Dec 29, 2008 at 9:50 PM, boB Gage <bg...@ekosystems.com> wrote:
>
>   
>> I've got a Mina application going that communicates with a variety of
>> devices through both serial and network interfaces.
>>
>> Part of this application is data-set simulations (ie fake far-end devices)
>> handled by using VmPipeAddress and VmPipeConnector objects.
>>
>> My data simulator puts data into the stream via session.write() calls; my
>> "normal" decoders pick up that data as if it had come from a real device.
>>
>> This set of objects works to an extent.   BUT....   data that is sent via
>> two consecutive session.write() calls does NOT show up as expected in the
>> decoder.
>>
>> For example, assume a decoder that wants packets delimited by 0x01 (start)
>> and 0xFF (end)
>>
>>  session.write(0x01 02 03 04 05)   followed by
>>  session.write(0x06 07 08 09 FF)
>>
>> Generates two calls to "decode" in the decoder object.
>> The first with five bytes 0x01 02 03 04 and 05 returns NEED_DATA because
>> the 0xFF end is not seen
>> The second with 5 bytes 0x06 07 08 09 FF returns NOT_OK because there is no
>> 0x01 start byte.
>>
>> I would have expected two calls, but different parameters:
>> First with 0x01 02 03 04 05 which would return NEED_DATA.  The second with
>> 0x01 02 03 04 05 06 07 08 09 FF which would return OK (after parsing)
>> because it had a full packet.
>>
>>
>> Am I suffering from unrealistic expectations??  Is this a known Mina bug???
>>   Have I just done something stupid???
>>
>>
>> Thanks in advance,
>> boB
>>
>>
>>     
>
>

Re: Issue with VmPipeAddress

Posted by Maarten Bosteels <mb...@gmail.com>.

Hi boB,

What you describe is the expected behaviour :-)
You're decoder is notified whenever new data arrives.  Accumulating this
data (when necessary) is the responsibility of the decoder.

Usually the easiest thing to do is extending CumulativeProtocolDecoder.

http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/codec/CumulativeProtocolDecoder.html

Also have a look at
http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html

Maarten


On Mon, Dec 29, 2008 at 9:50 PM, boB Gage <bg...@ekosystems.com> wrote:

> I've got a Mina application going that communicates with a variety of
> devices through both serial and network interfaces.
>
> Part of this application is data-set simulations (ie fake far-end devices)
> handled by using VmPipeAddress and VmPipeConnector objects.
>
> My data simulator puts data into the stream via session.write() calls; my
> "normal" decoders pick up that data as if it had come from a real device.
>
> This set of objects works to an extent.   BUT....   data that is sent via
> two consecutive session.write() calls does NOT show up as expected in the
> decoder.
>
> For example, assume a decoder that wants packets delimited by 0x01 (start)
> and 0xFF (end)
>
>  session.write(0x01 02 03 04 05)   followed by
>  session.write(0x06 07 08 09 FF)
>
> Generates two calls to "decode" in the decoder object.
> The first with five bytes 0x01 02 03 04 and 05 returns NEED_DATA because
> the 0xFF end is not seen
> The second with 5 bytes 0x06 07 08 09 FF returns NOT_OK because there is no
> 0x01 start byte.
>
> I would have expected two calls, but different parameters:
> First with 0x01 02 03 04 05 which would return NEED_DATA.  The second with
> 0x01 02 03 04 05 06 07 08 09 FF which would return OK (after parsing)
> because it had a full packet.
>
>
> Am I suffering from unrealistic expectations??  Is this a known Mina bug???
>   Have I just done something stupid???
>
>
> Thanks in advance,
> boB
>
>