You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Max Larsson <ma...@facilityboss.biz> on 2013/04/17 17:17:22 UTC
XML Protocol with initial ASCII handshake
Hi,
I'm using MINA to develop a client for a mainly XML based protocol.
And i have some problems to figure out how to realize it in the best
way. The cause of the problem is that the Protocol has upon
a successful connection to the IP/Port a initial procedure to select the
desired protocol and version is performed, before the actual XML
Protocol starts.
Up on now i created a StateMachine (similar to the TapeDeck Example on
the website) which models the initial procedure. That seems to work.
What i now wanted to do is, when this StateMachine has reached it
connect state (and the actually XML protocol starts), to forward
all message to another StateMaschine which works upon the first one.
Alternative i thought about to implement a custom IOConnector,
which uses the first StateMachine to establish a connection.
But for both ways i have no idea where to look or how to realize.
Is there any example with has similar approach?
BTW the hole problem can even been seen as two independent protocols,
where one is run over the other.
best regards
Max Larsson
Re: XML Protocol with initial ASCII handshake
Posted by Jon V <sy...@gmail.com>.
Data-->Filters-->Handler
Filters are pretty much the same as a handler just they can be stacked horizontally and there is only one handler.
--
Jon V
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Wednesday, April 17, 2013 at 1:56 PM, Max Larsson wrote:
> Hi Emmanuel,
>
> Somehow i habe completly missed The concept of of filters. You are right
> They seem to fit perfectly. Just a question are iohanders even iofilters?
>
> regrads
>
> Max
>
> Am 17.04.2013 um 19:16 schrieb Emmanuel Lécharny <elecharny@gmail.com (mailto:elecharny@gmail.com)>:
>
> > Le 4/17/13 6:48 PM, Max Larsson a écrit :
> > > Hi,
> > >
> > > The XML size is send in the front of the actual data.
> >
> > Ok, fine, then you can gather the XML in a raw byte[] while decoding
> > your own protocol. When done, you can parse the XML file in your
> > decoder. No need to have two filters; but you can do that. The message
> > sent to the next filter is just the payload (the XML data).
> >
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com (http://www.iktek.com)
> >
>
>
>
Re: XML Protocol with initial ASCII handshake
Posted by Max Larsson <ma...@facilityboss.biz>.
Hi Emmanuel,
Is there an example how to use a StateMachine (like the TapeDeck
example on the webpage) with an IOFilter?
regards
Max Larsson
On 18.04.13 02:00, Emmanuel Lécharny wrote:
> Le 4/17/13 7:56 PM, Max Larsson a écrit :
>> Hi Emmanuel,
>>
>> Somehow i habe completly missed The concept of of filters. You are right
>> They seem to fit perfectly. Just a question are iohanders even iofilters?
> No. They are two different interfaces. The IoHandler just process the
> events that are being generated by the IoService and propagated through
> the IoFilters.
>
>
Re: XML Protocol with initial ASCII handshake
Posted by "Jon V." <sy...@gmail.com>.
1) You obtain the next filter and call messageReceived there. Mina will
automatically wrap the last filter and call the handler.
2) nextFilter.filterWrite(session, new DefaultWriteRequest(out,
writeRequest.getFuture(), writeRequest.getDestination()));
On Fri, Apr 26, 2013 at 2:45 PM, Max Larsson
<ma...@facilityboss.biz>wrote:
> Hi Emmanuel,
>
> i have now a IoFilter which implement the initial connection
> establishing. But i have two question.
>
> 1) In my filter how do i send response to a messageRecived, so that
> the IoHandler does get informed.
>
> 2) The responses are only flushed out, during application shutdown.
> (J used flip() before sending the buffer via a DefaultWriteRequest
> down the nextFilter with filterWrite.
>
> I think the two questions relates somehow?
>
> regards
>
> Max
>
>
> On 18.04.13 02:00, Emmanuel Lécharny wrote:
>
>> Le 4/17/13 7:56 PM, Max Larsson a écrit :
>>
>>> Hi Emmanuel,
>>>
>>> Somehow i habe completly missed The concept of of filters. You are right
>>> They seem to fit perfectly. Just a question are iohanders even iofilters?
>>>
>> No. They are two different interfaces. The IoHandler just process the
>> events that are being generated by the IoService and propagated through
>> the IoFilters.
>>
>>
>>
>
> --
> ______________________________**______________________________**_________
>
> Max Larsson
> facilityboss GmbH
> Rheinstrasse 75, 64295 Darmstadt / Germany
> Handelsregister Darmstadt, HRB 86193
> Geschäftsführer: Dipl.-Inform. Max Lars Robert Larsson
>
> Mobil: +49 179 2184428
> Email: max.larsson@facilityboss.biz
>
Re: XML Protocol with initial ASCII handshake
Posted by Max Larsson <ma...@facilityboss.biz>.
Hi Emmanuel,
i have now a IoFilter which implement the initial connection
establishing. But i have two question.
1) In my filter how do i send response to a messageRecived, so that
the IoHandler does get informed.
2) The responses are only flushed out, during application shutdown.
(J used flip() before sending the buffer via a DefaultWriteRequest
down the nextFilter with filterWrite.
I think the two questions relates somehow?
regards
Max
On 18.04.13 02:00, Emmanuel Lécharny wrote:
> Le 4/17/13 7:56 PM, Max Larsson a écrit :
>> Hi Emmanuel,
>>
>> Somehow i habe completly missed The concept of of filters. You are right
>> They seem to fit perfectly. Just a question are iohanders even iofilters?
> No. They are two different interfaces. The IoHandler just process the
> events that are being generated by the IoService and propagated through
> the IoFilters.
>
>
--
_____________________________________________________________________
Max Larsson
facilityboss GmbH
Rheinstrasse 75, 64295 Darmstadt / Germany
Handelsregister Darmstadt, HRB 86193
Geschäftsführer: Dipl.-Inform. Max Lars Robert Larsson
Mobil: +49 179 2184428
Email: max.larsson@facilityboss.biz
Re: XML Protocol with initial ASCII handshake
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/17/13 7:56 PM, Max Larsson a écrit :
> Hi Emmanuel,
>
> Somehow i habe completly missed The concept of of filters. You are right
> They seem to fit perfectly. Just a question are iohanders even iofilters?
No. They are two different interfaces. The IoHandler just process the
events that are being generated by the IoService and propagated through
the IoFilters.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: XML Protocol with initial ASCII handshake
Posted by Max Larsson <ma...@facilityboss.biz>.
Hi Emmanuel,
Somehow i habe completly missed The concept of of filters. You are right
They seem to fit perfectly. Just a question are iohanders even iofilters?
regrads
Max
Am 17.04.2013 um 19:16 schrieb Emmanuel Lécharny <el...@gmail.com>:
> Le 4/17/13 6:48 PM, Max Larsson a écrit :
>> Hi,
>>
>> The XML size is send in the front of the actual data.
>
> Ok, fine, then you can gather the XML in a raw byte[] while decoding
> your own protocol. When done, you can parse the XML file in your
> decoder. No need to have two filters; but you can do that. The message
> sent to the next filter is just the payload (the XML data).
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: XML Protocol with initial ASCII handshake
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/17/13 6:48 PM, Max Larsson a écrit :
> Hi,
>
> The XML size is send in the front of the actual data.
Ok, fine, then you can gather the XML in a raw byte[] while decoding
your own protocol. When done, you can parse the XML file in your
decoder. No need to have two filters; but you can do that. The message
sent to the next filter is just the payload (the XML data).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: XML Protocol with initial ASCII handshake
Posted by Max Larsson <ma...@facilityboss.biz>.
Hi,
The XML size is send in the front of the actual data.
Regrads
Max
Am 17.04.2013 um 17:51 schrieb Emmanuel Lécharny <el...@gmail.com>:
> Le 4/17/13 5:17 PM, Max Larsson a écrit :
>> Hi,
> Hi,
>>
>> I'm using MINA to develop a client for a mainly XML based protocol.
> Not the simplest kind of protocol to decode ...
>
>>
>> And i have some problems to figure out how to realize it in the best
>> way. The cause of the problem is that the Protocol has upon
>> a successful connection to the IP/Port a initial procedure to select
>> the desired protocol and version is performed, before the actual XML
>> Protocol starts.
>>
>> Up on now i created a StateMachine (similar to the TapeDeck Example on
>> the website) which models the initial procedure. That seems to work.
>> What i now wanted to do is, when this StateMachine has reached it
>> connect state (and the actually XML protocol starts), to forward
>> all message to another StateMaschine which works upon the first one.
>> Alternative i thought about to implement a custom IOConnector,
>> which uses the first StateMachine to establish a connection.
> There is a big problem with this approach : you won't know when the XML
> data will be fully received before having parsed it...
>
> Unless your encapsulating protocol gives you the size of the XML data !
>
> Is it the case ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: XML Protocol with initial ASCII handshake
Posted by Jon <sy...@gmail.com>.
This is simple. Two filters. One for handshake one for protocol. After handshake is done. Disable the first through some session variable.
Sent from my iPhone
On Apr 17, 2013, at 11:51 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 4/17/13 5:17 PM, Max Larsson a écrit :
>> Hi,
> Hi,
>>
>> I'm using MINA to develop a client for a mainly XML based protocol.
> Not the simplest kind of protocol to decode ...
>
>>
>> And i have some problems to figure out how to realize it in the best
>> way. The cause of the problem is that the Protocol has upon
>> a successful connection to the IP/Port a initial procedure to select
>> the desired protocol and version is performed, before the actual XML
>> Protocol starts.
>>
>> Up on now i created a StateMachine (similar to the TapeDeck Example on
>> the website) which models the initial procedure. That seems to work.
>> What i now wanted to do is, when this StateMachine has reached it
>> connect state (and the actually XML protocol starts), to forward
>> all message to another StateMaschine which works upon the first one.
>> Alternative i thought about to implement a custom IOConnector,
>> which uses the first StateMachine to establish a connection.
> There is a big problem with this approach : you won't know when the XML
> data will be fully received before having parsed it...
>
> Unless your encapsulating protocol gives you the size of the XML data !
>
> Is it the case ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: XML Protocol with initial ASCII handshake
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/17/13 5:17 PM, Max Larsson a écrit :
> Hi,
Hi,
>
> I'm using MINA to develop a client for a mainly XML based protocol.
Not the simplest kind of protocol to decode ...
>
> And i have some problems to figure out how to realize it in the best
> way. The cause of the problem is that the Protocol has upon
> a successful connection to the IP/Port a initial procedure to select
> the desired protocol and version is performed, before the actual XML
> Protocol starts.
>
> Up on now i created a StateMachine (similar to the TapeDeck Example on
> the website) which models the initial procedure. That seems to work.
> What i now wanted to do is, when this StateMachine has reached it
> connect state (and the actually XML protocol starts), to forward
> all message to another StateMaschine which works upon the first one.
> Alternative i thought about to implement a custom IOConnector,
> which uses the first StateMachine to establish a connection.
There is a big problem with this approach : you won't know when the XML
data will be fully received before having parsed it...
Unless your encapsulating protocol gives you the size of the XML data !
Is it the case ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com