[Q] Obtaining the selectorHandler for a given ConnectorHandler

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Q] Obtaining the selectorHandler for a given ConnectorHandler

CigarMan

Here’s the context to my question:

 

I have a client communicating with hundreds of third party server concurrently. I want to write to the servers and process each responses received.

 

Upon receiving the bytes from the server,

 

- I need to parse the bytes into messages (protocol parsing)

- Process the parsed message according to the state into which my protocol is in. (stateful processing)

- Reply to the server’s request (negotiation of credentials) or

- Send a request of my own to the server.

 

Were I to write a server side application, I would write a filter chain (readFilter, myProtocolParser, myBusinessLogicActions) for the selectorHandler and I would be done! On the other hand, on the client side, looks to me like I’m stuck with the CallbackHandler to handle all of this! Doesn’t it break the separation of concern principle by having a CallbackHandler do too many things?

 

How about a FilterChain on the client side for each connection established? This way I could make use (reuse) of interfaces such as ProtocolParser.

 

I thought of applying a filter chain to a selectorHandler on the client side, but, correct me if I’m wrong, I guess this chain would apply to all my concurrent client connections instead of being one filterChain per connection.

 

 

Any thoughts or suggestion so I can come up with nice clients implemented according to what you had in mind for client side grizzly applications?

 

 

Thanks,

 

 

Simon

 

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Obtaining the selectorHandler for a given ConnectorHandler

Jeanfrancois Arcand-2
Hi Simon,

Simon Trudeau wrote:

> Here’s the context to my question:
>
>  
>
> I have a client communicating with hundreds of third party server
> concurrently. I want to write to the servers and process each responses
> received.
>
>  
>
> Upon receiving the bytes from the server,
>
>  
>
> - I need to parse the bytes into messages (protocol parsing)
>
> - Process the parsed message according to the state into which my
> protocol is in. (stateful processing)
>
> - Reply to the server’s request (negotiation of credentials) or
>
> - Send a request of my own to the server.
>
>  
>
> Were I to write a server side application, I would write a filter chain
> (readFilter, myProtocolParser, myBusinessLogicActions) for the
> selectorHandler and I would be done! On the other hand, on the client
> side, looks to me like I’m stuck with the CallbackHandler to handle all
> of this! Doesn’t it break the separation of concern principle by having
> a CallbackHandler do too many things?

You can always call the ProtocolChain from the CallbackHandler (this is
what I did for the SIP protocol implementation). What you do is:

ctx.getProtocolChain().execute(ctx);

As an example, for SIP, we do:

>         public void onRead(IOEvent<Context> ioEvent) {
>             try {
>                 Context ctx = ioEvent.attachment();
>                 ctx.setAttribute(IS_CLIENT_EXECUTION, true);
>                 SelectionKey key = ctx.getSelectionKey();
>                 if (!key.isValid()) {
>                     connectionManager.streams.remove(targetTuple);
>                     return;
>                 }
>
>                 ctx.setAttribute("tt", targetTuple);
>
>                 // disable OP_READ on key before doing anything else
>                 key.interestOps(key.interestOps() & (~SelectionKey.OP_READ));
>                 ctx.getProtocolChain().execute(ioEvent.attachment());
>             } catch (Throwable e) {
>                 if (logger.logSevere()) {
>                     logger.severe(e, "sip.stack.network.connection_read_failed", "tcp");
>                 }
>             }
>         }



>
>  
>
> How about a FilterChain on the client side for each connection
> established? This way I could make use (reuse) of interfaces such as
> ProtocolParser.

Yup this is what you should do :-)

>
>  
>
> I thought of applying a filter chain to a selectorHandler on the client
> side, but, correct me if I’m wrong, I guess this chain would apply to
> all my concurrent client connections instead of being one filterChain
> per connection.


You can have one FilterChain per connection if you use a statefull
ProtocolChainInstanceHandler (see my previous emails).

>
>  
>
>  
>
> Any thoughts or suggestion so I can come up with nice clients
> implemented according to what you had in mind for client side grizzly
> applications?

So far, your design looks good. But keep the questions coming, as they
will help me writing my next blog :-)

Thanks!!!!

-- Jeanfrancois


>
>  
>
>  
>
> Thanks,
>
>  
>
>  
>
> Simon
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]