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