[Q] selectorHandler, protocolChain and Out of Order messages

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

[Q] selectorHandler, protocolChain and Out of Order messages

CigarMan

Assuming I am developing a client application who makes many concurrent client connections to different servers. My client side implementation makes use of one selectorHandler with its protocolChain and many connectorHandlers to establish the concurrent connections with the different servers.

 

My questions are:

 

How do the protocol filters in the protocolChain make the different between the different source (servers) when handling byte buffers? When reaching myBusinessLogicFilter, I need to be able to route the messages received according to from where they were from.

 

How does the protocolParser deals with out of order messages (when communicating over UDP for example) or with packets which have been dropped? How does it (ProtocolParser) deal with messages coming from many different sources (servers)? Won’t there be problems with message reassembly?

 

Thanks (code snippet would be greatly appreciated),

 

 

 

Simon

 

Reply | Threaded
Open this post in threaded view
|

Re: [Q] selectorHandler, protocolChain and Out of Order messages

Jeanfrancois Arcand-2

Salut,


Simon Trudeau wrote:

> Assuming I am developing a client application who makes many concurrent
> client connections to different servers. My client side implementation
> makes use of one selectorHandler with its protocolChain and many
> connectorHandlers to establish the concurrent connections with the
> different servers.
>
>  
>
> My questions are:
>
>  
>
> How do the protocol filters in the protocolChain make the different
> between the different source (servers) when handling byte buffers?

ctx.getSelectorHandler()


When
> reaching myBusinessLogicFilter, I need to be able to route the messages
> received according to from where they were from.
>
>  
>
> How does the protocolParser deals with out of order messages (when
> communicating over UDP for example) or with packets which have been
> dropped?

Dropped packet will never reach the server, Grizzly cannot do anything
for that....same for the out of order as this is protocol dependent.
Hence you need to find, in your ProtocolFilter, if the packet wasn't
ordered properly.


How does it (ProtocolParser) deal with messages coming from
> many different sources (servers)? Won’t there be problems with message
> reassembly?

Again, since it is protocol dependent (your protocol), the logic must be
implemented inside your ProtocolFilter. I will look at your other
question and then send you an example.

A+
-- jeanfrancois


>
>  
>
> Thanks (code snippet would be greatly appreciated),
>
>  
>
>  
>
>  
>
> Simon
>
>  
>

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