Hi JianXing Yi,
I can only answer question 3 :
in regards to sate, in my opinion grizzly framework doesn't change the semantics of the original java nio selector . Which is great because you programm to a known model.
So statewise your state is in the selectionKey which is given to you by the grizzly Context Object in a Filter.
So when you do for example server-client writes you just write with the help of the selectionKey. As long as your selectionKey does not get canceled you have a open connection to your client. If you need to keep state then you could attach your state to the selectionKey.
You can look at "How-to attach an ID to a Connection?"
https://grizzly.dev.java.net/servlets/ReadMsg?listName=users&msgNo=936
to see an example on how to attach something to a connection.
But for your 5 times request-response interaction example you do not need to attach anything to the selectionKey.
You could use a Protocol session ID to keep track of state on the server.
On the first connection of a client to the server I would just create a session ID which the server sends back to the client.
and the client then always uses in its subsequent requests.
You can create a ProtocolParserFilter to parse this session Id out of the request.
Does this answer question 3?
Many Greetings
John
> Betreff: Re: How to implement the client's message flow based on async
> read/write?
>
>
>
> Hello John,
> Great thanks for your help! European soccer champinship also attract
> lot of us :-) Enjoy! It's really a good news for your samples, the
> sooner the better :-) In my case, I invoke the ProtocolFilter in
> CallbackHandler.onConnect() to send the request to the server and it
> works, or in another word, the
> CallbackHandler.onConnect() kicks off the protocol interaction.
> Because I really want the ProtocolFilter to manage its own
> state/operation itselft without interaction with the CallbackHandler.
> But there are still problems, those are about 1. Context operation
> type switching or SelectionKey interests switching Could you pls. give
> a brief explanation of these switching, maybe something about
> Context.setCurrentOpType(), KeyRegistrationState, or anything else?
> 2. Asynchronously reading/writing in ProtocolFilters In my case, I use
> an asynchronous reading operaiton to receive the server's simple
> response. Unfortunately, this leads to about 50% cpu polling :-(.
> 3. State management in ProtocolFilter
> In my case, I try to test a stateful protocol interaction by extending
> the interaction process to this: the request-response interaction will
> be repeated 5 times and then the client initiates to close the
> connection. Could you pls. give a brief explanation about how to
> implement state management in ProtocolFilter?
>
> 2008/6/12 John ROM <snake-john_at_gmx.de>:
>
> ProtocolParser,Filter are mainly for reading.
> Of course you can always call your TCPConnectorHandler from a filter.
>
> you could look at
>
> "Obtaining the selectorHandler for a given ConnectorHandler"
>
> https://grizzly.dev.java.net/servlets/ReadMsg?listName=users&msgNo=678
>
> for advice on setting up a chain in a client for reading.
>
> many Greetings.
> p.s:
> I am working on a complete example for client/server communication
> with a client protocolParser and will try to publish it under the
> samples directory.
> I should have it done at the end of the month after the european
> soccer championship...
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx