[Q] How-to client Protocol

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

[Q] How-to client Protocol

CigarMan

I’m looking for help building a TCP client with a specific protocol :

 

If server is password protected:

 

  1. Client connects to server
  2. Server sends password prompt to client
  3. Client sends server’s password
  4. Server sends acknowledgement
  5. Client sends request
  6. Server sends reply
  7. Repeat step 5 and 6

 

If server is not password protected:

 

  1. Client connects to server
  2. Client sends request
  3. Server sends reply
  4. Repeat step 2 and 3

 

How should I go about implementing this protocol? In once case, the client, upon establishing a connection, can send a request right away in the other case, it must wait for the server to negotiate the password.

 

What’s the right way to handle protocol specific data exchange on the client side?

 

My first guess would be to create a custom CallbackHandler to trigger the password negociation upon connecting to the server like so…

 

connector_handler.connect(new InetSocketAddress(host,port), 
new CallbackHandler<Context>() 
{
public void onConnect(IOEvent<Context> e) 
{
SelectionKey k = e.attachment().getSelectionKey();
System.out.println("Callbackhandler: OnConnect...");
try
{
        connector_handler.finishConnect(k);
 
        //Negociate password password exchange here
} catch(Exception ex) 
{
        System.out.println("exception in CallbackHandler:"+ex.getMessage());
}
e.attachment().getSelectorHandler().register(k,SelectionKey.OP_READ);
}
 
public void onRead(IOEvent<Context> e){}
public void onWrite(IOEvent<Context> e){}
});
 
It might work… but it definitely doesn’t look very nice. Is there some sort of state machine facility to deal with this kind of situation? I guess there must be since Grizzly is implemented with protocols such as SIP.
 
There is also something called a ProtocolFilter, I guess it could be better suited than using the CallbackHandler…eventhough I need to define a behaviour OnConnection…
 
Using a ProtocolFilter, how would I go about making it stateful and maintaining state information between invocation of the ProtocolFilter? I guess it has something to do with the Context object… But how do you store user defined states in this object? Do I have to overload it?
 
 
Well, I guess I have a lot of interrogations! :.) Are there any test cases in the Grizzly code base that could help me? Are there any tutorials, code samples, on the topic?
 
 
Thanks for your help,

 

 

Simon

 

Reply | Threaded
Open this post in threaded view
|

Re: [Q] How-to client Protocol

Jeanfrancois Arcand-2
Hi Simon (sound french :-))

Simon Trudeau wrote:

> I’m looking for help building a TCP client with a specific protocol :
>
>  
>
> If server is password protected:
>
>  
>
>    1. Client connects to server
>    2. Server sends password prompt to client
>    3. Client sends server’s password
>    4. Server sends acknowledgement
>    5. Client sends request
>    6. Server sends reply
>    7. Repeat step 5 and 6
>
>  
>
> If server is not password protected:
>
>  
>
>    1. Client connects to server
>    2. Client sends request
>    3. Server sends reply
>    4. Repeat step 2 and 3
>
>  
>
> How should I go about implementing this protocol? In once case, the
> client, upon establishing a connection, can send a request right away in
> the other case, it must wait for the server to negotiate the password.
>
>  
>
> What’s the right way to handle protocol specific data exchange on the
> client side?

With Grizzly, you don't have to implement such mechanism, as it already
support it by default. I will first explain without too much details, so
feel free to ask questions if I'm unclear. But first, are you planning
to use a single port for both TLS (secure) and TCP (unsecure) or will
you have two ports? We have a mechanism that support a single port:

http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.html

Might want to use that (but for now, let's focus on not using it). For
the server side, you need to add to SelectorHandler:

Controller controller = new Controller();
controller.addSelectorHandler(new SSLSelectorHandler());
controller.addSelectorHandler(new TCPSelectorHandler());

This is just a code snippet. Next the client.


>
>  
>
> My first guess would be to create a custom CallbackHandler to trigger
> the password negociation upon connecting to the server like so…

Right,



>
>  
>
> connector_handler.connect(new InetSocketAddress(host,port),
>
> new CallbackHandler<Context>()
>
> {
>
> public void onConnect(IOEvent<Context> e)
>
> {
>
> SelectionKey k = e.attachment().getSelectionKey();
>
> System.out.println("Callbackhandler: OnConnect...");
>
> try
>
> {
>
>         connector_handler.finishConnect(k);
>
>  
>
>         //*Negociate password password exchange here*
>
> } catch(Exception ex)
>
> {
>
>         System.out.println("exception in CallbackHandler:"+ex.getMessage());
>
> }
>
> e.attachment().getSelectorHandler().register(k,SelectionKey.OP_READ);
>
> }
>
>  
>
> public void onRead(IOEvent<Context> e){}
>
> public void onWrite(IOEvent<Context> e){}
>
> });
>
>  
>
> It might work… but it definitely doesn’t look very nice. Is there some sort of state machine facility to deal with this kind of situation? I guess there must be since Grizzly is implemented with protocols such as SIP.

But how/where is your password (what kind of form does it take). Usually
  you add a certificate on the client and server side, and Grizzly will
do the negociation for you. Is that what you have in mind?



>
>  
>
> There is also something called a ProtocolFilter, I guess it could be better suited than using the CallbackHandler…eventhough I need to define a behaviour OnConnection…

ProtocolFilter are used on the server side usually (but can be used on
the client side as well...SIP does use it). For your SSL stuff, you will
use the SSLReadFilter, and for TCP/UDP, the ReadFilter. What you usually
do is:

91           Controller sel = new Controller();
92           sel.setProtocolChainInstanceHandler(new
DefaultProtocolChainInstanceHandler(){
93               public ProtocolChain poll() {
94                   ProtocolChain protocolChain = protocolChains.poll();
95                   if (protocolChain == null){
96                       protocolChain = new DefaultProtocolChain();
97                       protocolChain.addFilter(new ReadFilter());
98                       protocolChain.addFilter(*** What you need to do
with the bytes ****);
99                   }
100                  return protocolChain;
101              }
102         });

This is the server side :-)

>
>  
>
> Using a ProtocolFilter, how would I go about making it stateful and maintaining state information between invocation of the ProtocolFilter? I guess it has something to do with the Context object… But how do you store user defined states in this object? Do I have to overload it?

Context.setAttribute() or SelectorHandler.setAttribute or
Controller.setAttribute. You can also makes your ProtocolFilter statefull:

>         ProtocolChainInstanceHandler pciHandler =
>                 new ProtocolChainInstanceHandler() {
>
>             final private ProtocolChain protocolChain = new DefaultProtocolChain();
>
>             public ProtocolChain poll() {
>                 return protocolChain;
>             }
>
>             public boolean offer(ProtocolChain instance) {
>                 return true;
>             }
>         };
>         controller.setProtocolChainInstanceHandler(pciHandler);

So you can store you state inside any ProtocolFilter. But


>
>  
>
>  
>
> Well, I guess I have a lot of interrogations! :.)

Keep them coming :-) Our documentation really really sucks :-)


Are there any test cases in the Grizzly code base that could help me?



Are there any tutorials, code samples, on the topic?

There is a couple on grizzly.dev.java.net. A good starter is:

http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.html

and the SIP example is here:

http://weblogs.java.net/blog/jfarcand/archive/2007/11/supporting_the.html

Erick also proposed a tutorial:

http://www.nabble.com/Grizzly-on-the-client-side%2C-a-modest-tutorial-td15643977.html

But the best source of information is the mailing list. We are all happy
to help so bombard us with questions :-)

Thanks!

-- Jeanfrancois



>
>  
>
>  
>
> Thanks for your help,
>
>  
>
>  
>
> Simon
>
>  
>

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

Reply | Threaded
Open this post in threaded view
|

RE: Re: [Q] How-to client Protocol

CigarMan
Of course it sounds french, I'm from Montreal! :.)

Your tutorial on SIP

http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.
html

and the one from Erick

http://www.nabble.com/Grizzly-on-the-client-side%2C-a-modest-tutorial-td
15643977.html

were real breakthrough for me, they gave me the starting point I needed
to understand Grizzly better. By the way, I am still anxiously waiting
to the follow up to your Sip tutorial ;.P

Now moving onward to my not so obvious stuff...

Thanks for the quick reply. I so much wish I could make use of something
standard such as SSL but unfortunately I can't. I am using Grizzly to
communicate to a legacy device (actually thousands of them...) which
implements its own custom password negotiation protocol. That is why I
need to implement my own protocol. Unfortunately, I only have control of
the code on my client application side, the server side being the legacy
device.

So, what would you recommend?

I think I cannot avoid it, I need to implement my own protocolFilter on
the client side.

My idea is the following...

***** Client Snippet ****

Controller controller = new Controller();
TCPSelectorHandler mySelectorHandler = new TCPSelectorHandler() ;

mySelectorHandler.setProtocolChainInstanceHandler(new
DefaultProtocolChainInstanceHandler(){
        public ProtocolChain poll()
        {
                ProtocolChain protocolChain = protocolChains.poll();
                if (protocolChain == null)
                {
                        protocolChain = new DefaultProtocolChain();
                        protocolChain.addFilter(new ReadFilter());
                        protocolChain.addFilter(new MyProtocolFilter());
                }
                return protocolChain;
        }
});

controller.addSelectorHandler(mySelectorHandler);

...

TCPConnectorHandler myConnectorHandler = (TCPConnectorHandler)
controller.acquireConnectorHandler(Controller.Protocol.TCP);
myConnectorHandler.connect(new InetSocketAddress(host, port));

...

Public class MyProtocolFilter() implements ProtocolFilter
{
        public boolean execute(Context ctx) throws IOException
        {
                - Set custom state information in ctx object according
to my protocol
                - Given a certain custom state stored in the ctx object,
process the message according to the given state.
        }
}

************

Does my pseudo code make sense or am I totally wrong?

How should I go about managing state for my protocol? Should I store
them in the Context object or declare them as private variable in the
MyProtocolFilter() object? The SSLReadFilter seems to hold a private
SSLContext...

I am not sure I understand the life cycle of the MyProtocolFilter? Is my
instance alive as long as I have a connection? It is important for me to
know that since I need to make the appropriate cleanup if the connection
drops or an exception is raised.


Thanks for your help,


Simon

By the way, a tutorial on exception handling using Grizzly could be
great!


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: February-29-08 4:01 PM
To: [hidden email]
Subject: Re: [Q] How-to client Protocol

Hi Simon (sound french :-))

Simon Trudeau wrote:

> I'm looking for help building a TCP client with a specific protocol :
>
>  
>
> If server is password protected:
>
>  
>
>    1. Client connects to server
>    2. Server sends password prompt to client
>    3. Client sends server's password
>    4. Server sends acknowledgement
>    5. Client sends request
>    6. Server sends reply
>    7. Repeat step 5 and 6
>
>  
>
> If server is not password protected:
>
>  
>
>    1. Client connects to server
>    2. Client sends request
>    3. Server sends reply
>    4. Repeat step 2 and 3
>
>  
>
> How should I go about implementing this protocol? In once case, the
> client, upon establishing a connection, can send a request right away
in
> the other case, it must wait for the server to negotiate the password.
>
>  
>
> What's the right way to handle protocol specific data exchange on the
> client side?

With Grizzly, you don't have to implement such mechanism, as it already
support it by default. I will first explain without too much details, so

feel free to ask questions if I'm unclear. But first, are you planning
to use a single port for both TLS (secure) and TCP (unsecure) or will
you have two ports? We have a mechanism that support a single port:

http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.ht
ml

Might want to use that (but for now, let's focus on not using it). For
the server side, you need to add to SelectorHandler:

Controller controller = new Controller();
controller.addSelectorHandler(new SSLSelectorHandler());
controller.addSelectorHandler(new TCPSelectorHandler());

This is just a code snippet. Next the client.


>
>  
>
> My first guess would be to create a custom CallbackHandler to trigger
> the password negociation upon connecting to the server like so...

Right,



>
>  
>
> connector_handler.connect(new InetSocketAddress(host,port),
>
> new CallbackHandler<Context>()
>
> {
>
> public void onConnect(IOEvent<Context> e)
>
> {
>
> SelectionKey k = e.attachment().getSelectionKey();
>
> System.out.println("Callbackhandler: OnConnect...");
>
> try
>
> {
>
>         connector_handler.finishConnect(k);
>
>  
>
>         //*Negociate password password exchange here*
>
> } catch(Exception ex)
>
> {
>
>         System.out.println("exception in
CallbackHandler:"+ex.getMessage());

>
> }
>
> e.attachment().getSelectorHandler().register(k,SelectionKey.OP_READ);
>
> }
>
>  
>
> public void onRead(IOEvent<Context> e){}
>
> public void onWrite(IOEvent<Context> e){}
>
> });
>
>  
>
> It might work... but it definitely doesn't look very nice. Is there
some sort of state machine facility to deal with this kind of situation?
I guess there must be since Grizzly is implemented with protocols such
as SIP.

But how/where is your password (what kind of form does it take). Usually

  you add a certificate on the client and server side, and Grizzly will
do the negociation for you. Is that what you have in mind?



>
>  
>
> There is also something called a ProtocolFilter, I guess it could be
better suited than using the CallbackHandler...eventhough I need to
define a behaviour OnConnection...

ProtocolFilter are used on the server side usually (but can be used on
the client side as well...SIP does use it). For your SSL stuff, you will

use the SSLReadFilter, and for TCP/UDP, the ReadFilter. What you usually

do is:

91           Controller sel = new Controller();
92           sel.setProtocolChainInstanceHandler(new
DefaultProtocolChainInstanceHandler(){
93               public ProtocolChain poll() {
94                   ProtocolChain protocolChain =
protocolChains.poll();
95                   if (protocolChain == null){
96                       protocolChain = new DefaultProtocolChain();
97                       protocolChain.addFilter(new ReadFilter());
98                       protocolChain.addFilter(*** What you need to do

with the bytes ****);
99                   }
100                  return protocolChain;
101              }
102         });

This is the server side :-)

>
>  
>
> Using a ProtocolFilter, how would I go about making it stateful and
maintaining state information between invocation of the ProtocolFilter?
I guess it has something to do with the Context object... But how do you
store user defined states in this object? Do I have to overload it?

Context.setAttribute() or SelectorHandler.setAttribute or
Controller.setAttribute. You can also makes your ProtocolFilter
statefull:

>         ProtocolChainInstanceHandler pciHandler =
>                 new ProtocolChainInstanceHandler() {
>
>             final private ProtocolChain protocolChain = new
DefaultProtocolChain();

>
>             public ProtocolChain poll() {
>                 return protocolChain;
>             }
>
>             public boolean offer(ProtocolChain instance) {
>                 return true;
>             }
>         };
>         controller.setProtocolChainInstanceHandler(pciHandler);

So you can store you state inside any ProtocolFilter. But


>
>  
>
>  
>
> Well, I guess I have a lot of interrogations! :.)

Keep them coming :-) Our documentation really really sucks :-)


Are there any test cases in the Grizzly code base that could help me?



Are there any tutorials, code samples, on the topic?

There is a couple on grizzly.dev.java.net. A good starter is:

http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.
html

and the SIP example is here:

http://weblogs.java.net/blog/jfarcand/archive/2007/11/supporting_the.htm
l

Erick also proposed a tutorial:

http://www.nabble.com/Grizzly-on-the-client-side%2C-a-modest-tutorial-td
15643977.html

But the best source of information is the mailing list. We are all happy

to help so bombard us with questions :-)

Thanks!

-- Jeanfrancois



>
>  
>
>  
>
> Thanks for your help,
>
>  
>
>  
>
> Simon
>
>  
>

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


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

Reply | Threaded
Open this post in threaded view
|

Re: [Q] How-to client Protocol

Jeanfrancois Arcand-2


Simon Trudeau wrote:
> Of course it sounds french, I'm from Montreal! :.)

And I'm on the 15 North :-)

>
> Your tutorial on SIP
>
> http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.
> html
>
> and the one from Erick
>
> http://www.nabble.com/Grizzly-on-the-client-side%2C-a-modest-tutorial-td
> 15643977.html
>
> were real breakthrough for me, they gave me the starting point I needed
> to understand Grizzly better. By the way, I am still anxiously waiting
> to the follow up to your Sip tutorial ;.P

:-) Working on it, but have all kind of firedrill this week :-)

>
> Now moving onward to my not so obvious stuff...
>
> Thanks for the quick reply. I so much wish I could make use of something
> standard such as SSL but unfortunately I can't. I am using Grizzly to
> communicate to a legacy device (actually thousands of them...) which
> implements its own custom password negotiation protocol. That is why I
> need to implement my own protocol. Unfortunately, I only have control of
> the code on my client application side, the server side being the legacy
> device.
>
> So, what would you recommend?
>
> I think I cannot avoid it, I need to implement my own protocolFilter on
> the client side.
>
> My idea is the following...
>
> ***** Client Snippet ****
>
> Controller controller = new Controller();
> TCPSelectorHandler mySelectorHandler = new TCPSelectorHandler() ;
>
> mySelectorHandler.setProtocolChainInstanceHandler(new
> DefaultProtocolChainInstanceHandler(){
> public ProtocolChain poll()
> {
> ProtocolChain protocolChain = protocolChains.poll();
> if (protocolChain == null)
> {
> protocolChain = new DefaultProtocolChain();
> protocolChain.addFilter(new ReadFilter());
> protocolChain.addFilter(new MyProtocolFilter());
> }
> return protocolChain;
> }
> });
>
> controller.addSelectorHandler(mySelectorHandler);
>
> ...
>
> TCPConnectorHandler myConnectorHandler = (TCPConnectorHandler)
> controller.acquireConnectorHandler(Controller.Protocol.TCP);
> myConnectorHandler.connect(new InetSocketAddress(host, port));
>
> ...
>
> Public class MyProtocolFilter() implements ProtocolFilter
> {
> public boolean execute(Context ctx) throws IOException
> {
> - Set custom state information in ctx object according
> to my protocol
> - Given a certain custom state stored in the ctx object,
> process the message according to the given state.

So far so good.


> }
> }
>
> ************
>
> Does my pseudo code make sense or am I totally wrong?

Make a lot of senses!

>
> How should I go about managing state for my protocol?

You have two solutions:

(1) Use a statefull ProtocolChain/ProtocolChainInstanceHandler. That
means that each Thread will execute their own instance of ProtocolFilter
(your myProtocolFilter). Some like:


>         ProtocolChainInstanceHandler pciHandler =
>                 new ProtocolChainInstanceHandler() {
>
>             final private ConcurrentLinkedQueue<ProtocolChain> protocolChains = ...
>             public ProtocolChain poll() {
>                 return protocolChains.poll();
>             }
>
>             public boolean offer(ProtocolChain instance) {
>                 return protocolChains.offer(instance);
>             }
>         };
>         controller.setProtocolChainInstanceHandler(pciHandler);

And then you can store the information inside the Context. Or you can

(2) Store the information inside the SelectorHandler's attributes list

ctx.getSelectorHandler().setAttribute(...);

The information will be available to all ProtocolFlter via the ctx
interface.

Should I store
> them in the Context object or declare them as private variable in the
> MyProtocolFilter() object? The SSLReadFilter seems to hold a private
> SSLContext...
>
> I am not sure I understand the life cycle of the MyProtocolFilter? Is my
> instance alive as long as I have a connection? It is important for me to
> know that since I need to make the appropriate cleanup if the connection
> drops or an exception is raised.

Depending on how you create your ProtocolChain, you may have several
ProtocolChain (hence ProtocolFilter) inside your
ProtocolChainInstanceHandler. That may impact performance if you need to
serve 20 000 connections. The alternative is to use a stateless
ProtocolChainInstanceHandler:


>         ProtocolChainInstanceHandler pciHandler =
>                 new ProtocolChainInstanceHandler() {
>
>             final private ProtocolChain protocolChain = new DefaultProtocolChain();
>
>             public ProtocolChain poll() {
>                 return protocolChain;
>             }
>
>             public boolean offer(ProtocolChain instance) {
>                 return true;
>             }
>         };
>         controller.setProtocolChainInstanceHandler(pciHandler);

That means only 1 ProtocolChain will be created (and only one
myProtocolChain).

If the connection drop, your ProtocolFilter will never get deleted
unless you implement the behavior (but I would not recommend that).

>
>
> Thanks for your help,
>
>
> Simon
>
> By the way, a tutorial on exception handling using Grizzly could be
> great!

Merci!

-- Jeanfrancois

>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: February-29-08 4:01 PM
> To: [hidden email]
> Subject: Re: [Q] How-to client Protocol
>
> Hi Simon (sound french :-))
>
> Simon Trudeau wrote:
>> I'm looking for help building a TCP client with a specific protocol :
>>
>>  
>>
>> If server is password protected:
>>
>>  
>>
>>    1. Client connects to server
>>    2. Server sends password prompt to client
>>    3. Client sends server's password
>>    4. Server sends acknowledgement
>>    5. Client sends request
>>    6. Server sends reply
>>    7. Repeat step 5 and 6
>>
>>  
>>
>> If server is not password protected:
>>
>>  
>>
>>    1. Client connects to server
>>    2. Client sends request
>>    3. Server sends reply
>>    4. Repeat step 2 and 3
>>
>>  
>>
>> How should I go about implementing this protocol? In once case, the
>> client, upon establishing a connection, can send a request right away
> in
>> the other case, it must wait for the server to negotiate the password.
>>
>>  
>>
>> What's the right way to handle protocol specific data exchange on the
>> client side?
>
> With Grizzly, you don't have to implement such mechanism, as it already
> support it by default. I will first explain without too much details, so
>
> feel free to ask questions if I'm unclear. But first, are you planning
> to use a single port for both TLS (secure) and TCP (unsecure) or will
> you have two ports? We have a mechanism that support a single port:
>
> http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.ht
> ml
>
> Might want to use that (but for now, let's focus on not using it). For
> the server side, you need to add to SelectorHandler:
>
> Controller controller = new Controller();
> controller.addSelectorHandler(new SSLSelectorHandler());
> controller.addSelectorHandler(new TCPSelectorHandler());
>
> This is just a code snippet. Next the client.
>
>
>>  
>>
>> My first guess would be to create a custom CallbackHandler to trigger
>> the password negociation upon connecting to the server like so...
>
> Right,
>
>
>
>>  
>>
>> connector_handler.connect(new InetSocketAddress(host,port),
>>
>> new CallbackHandler<Context>()
>>
>> {
>>
>> public void onConnect(IOEvent<Context> e)
>>
>> {
>>
>> SelectionKey k = e.attachment().getSelectionKey();
>>
>> System.out.println("Callbackhandler: OnConnect...");
>>
>> try
>>
>> {
>>
>>         connector_handler.finishConnect(k);
>>
>>  
>>
>>         //*Negociate password password exchange here*
>>
>> } catch(Exception ex)
>>
>> {
>>
>>         System.out.println("exception in
> CallbackHandler:"+ex.getMessage());
>> }
>>
>> e.attachment().getSelectorHandler().register(k,SelectionKey.OP_READ);
>>
>> }
>>
>>  
>>
>> public void onRead(IOEvent<Context> e){}
>>
>> public void onWrite(IOEvent<Context> e){}
>>
>> });
>>
>>  
>>
>> It might work... but it definitely doesn't look very nice. Is there
> some sort of state machine facility to deal with this kind of situation?
> I guess there must be since Grizzly is implemented with protocols such
> as SIP.
>
> But how/where is your password (what kind of form does it take). Usually
>
>   you add a certificate on the client and server side, and Grizzly will
> do the negociation for you. Is that what you have in mind?
>
>
>
>>  
>>
>> There is also something called a ProtocolFilter, I guess it could be
> better suited than using the CallbackHandler...eventhough I need to
> define a behaviour OnConnection...
>
> ProtocolFilter are used on the server side usually (but can be used on
> the client side as well...SIP does use it). For your SSL stuff, you will
>
> use the SSLReadFilter, and for TCP/UDP, the ReadFilter. What you usually
>
> do is:
>
> 91           Controller sel = new Controller();
> 92           sel.setProtocolChainInstanceHandler(new
> DefaultProtocolChainInstanceHandler(){
> 93               public ProtocolChain poll() {
> 94                   ProtocolChain protocolChain =
> protocolChains.poll();
> 95                   if (protocolChain == null){
> 96                       protocolChain = new DefaultProtocolChain();
> 97                       protocolChain.addFilter(new ReadFilter());
> 98                       protocolChain.addFilter(*** What you need to do
>
> with the bytes ****);
> 99                   }
> 100                  return protocolChain;
> 101              }
> 102         });
>
> This is the server side :-)
>
>>  
>>
>> Using a ProtocolFilter, how would I go about making it stateful and
> maintaining state information between invocation of the ProtocolFilter?
> I guess it has something to do with the Context object... But how do you
> store user defined states in this object? Do I have to overload it?
>
> Context.setAttribute() or SelectorHandler.setAttribute or
> Controller.setAttribute. You can also makes your ProtocolFilter
> statefull:
>
>>         ProtocolChainInstanceHandler pciHandler =
>>                 new ProtocolChainInstanceHandler() {
>>
>>             final private ProtocolChain protocolChain = new
> DefaultProtocolChain();
>>             public ProtocolChain poll() {
>>                 return protocolChain;
>>             }
>>
>>             public boolean offer(ProtocolChain instance) {
>>                 return true;
>>             }
>>         };
>>         controller.setProtocolChainInstanceHandler(pciHandler);
>
> So you can store you state inside any ProtocolFilter. But
>
>
>>  
>>
>>  
>>
>> Well, I guess I have a lot of interrogations! :.)
>
> Keep them coming :-) Our documentation really really sucks :-)
>
>
> Are there any test cases in the Grizzly code base that could help me?
>
>
>
> Are there any tutorials, code samples, on the topic?
>
> There is a couple on grizzly.dev.java.net. A good starter is:
>
> http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.
> html
>
> and the SIP example is here:
>
> http://weblogs.java.net/blog/jfarcand/archive/2007/11/supporting_the.htm
> l
>
> Erick also proposed a tutorial:
>
> http://www.nabble.com/Grizzly-on-the-client-side%2C-a-modest-tutorial-td
> 15643977.html
>
> But the best source of information is the mailing list. We are all happy
>
> to help so bombard us with questions :-)
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>>  
>>
>>  
>>
>> Thanks for your help,
>>
>>  
>>
>>  
>>
>> Simon
>>
>>  
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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