Hi John,
Many thanks. I'll try this.
Regards,
-Yi Bing
2008/6/13 John ROM <snake-john_at_gmx.de>:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>