Radim Kolar SF.NET wrote:
>> Yes probably. Working on an async write queue is exactly what you need I
>> suspect. What I was having in mind is to be able, from a Context (using the
>> getAttribute()), to get a reference to a write queue where you can register
>> something like that:
>>
>> ((WriteQueue)ctx.getAttribute(Grizzly.WriteQueue)).write(new
>> WriteCallbackHandler(SelectionKey) {
>>
>> public void onComplete(...){
>> }
>>
>> public void onException(...){
>> }
>> });
> i think about this scheme:
>
> Allow multiple protocolchains registration per controller.
>
> 1.
> controller.setProtocolChainInstanceHandler(chain,operation) OP_READ or OP_WRITE
> etc..) or some kind of mask OP_READ|OP_WRITE
That sound a good idea.
>
> 2. Use context for passing protocol state between chains
> This needs 1:1 Context vs SelectionKeys mapping. Bind context to SelectionKey
Right now the Context is associated with the SelectionKey. What you
means is doing something like key.attach(context), the register the key
and re-use the Context from that key?
>
> 3. In filter reader chain just alter protocol state in context or write raw data into context write buffer) and switch SelectionKey on Selector from OP_READ to OP_WRITE and return false; (don't call next filter in read chain).
Should this can be done in another filter instead?
>
> 4. in next select() loop
> SelectionKey + Context will arrive into protocol writer chain:
Yes.
>
> protocol dependent writer (add headers, check protocol state from context,
> extract data to be written from Context and put result into TLS bytebuffer)
> if no more data to write switch to reader or close connection.
> WriteFilter.java (generic bytes writer, should not close connection after all data are send)
Agree although I still think the current WriteFilter is not doing that :-)
>
> 5.
> consider writing new filter classes.
> EOFFilter() - cancel connection if no more data needs to be sent.
> SwitchToRead() - switch to read mode if no more data needs to be sent.
> SwitchToWrite() ditto
:-) Sound good :-) Patches/Contributions are welcome :-)
Thanks
-- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>