users@grizzly.java.net

Re: WELCOME to users_at_grizzly.dev.java.net

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Wed, 05 Mar 2008 12:19:47 +0100

Hello Sebastien,

thanks for your info :)

Think we can split your requirements to two parts:
(1) Server side, which will process client connections.
(2) Client side, which will from time to time connect to provider
servers to update data.

As the server side (1) base implementation you can take EchoServer
example [1], but instead EchoFilter, which is used in example, you
will need to plug your custom ProtocolFilter.
You told, that clients will subscribe for updates, so you will have
specific client<->server protocol, right? It could make sense to
implement custom ProtocolParser [2], which will split incoming client
messages, parse them and pass to next ProtocolFilter, where you will
able to process parsed requests packet-by-packet.

As for client side (2) it also should not be difficult. Here is
example how it could be implemented [3]. From you description, looks
like client side (2) will not be demanding, so possibly, could be
easier to implement it with pure Sockets.

Thanks.

WBR,
Alexey.


[1] http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.html
[2] http://weblogs.java.net/blog/sdo/archive/2007/12/grizzly_protoco.html
[3] public void receiveUpdateFromProviderX(InetSocketAddress
address) {
         // Controller is shared with Server part (1)
         final ConnectorHandler tcpConnector =
                  
controller.acquireConnectorHandler(Controller.Protocol.TCP);
         tcpConnector.connect(address, new CallbackHandler<Context>() {

             public void onConnect(IOEvent<Context> ioEvent) {
                 SelectionKey connectedKey =
ioEvent.attachment().getSelectionKey();
                 try {
                     tcpConnector.finishConnect(connectedKey);
                 } catch(IOException e) {
                     //TODO notify about exception happened during
connect and exit
                 }
                 //TODO notify connected
             }

             public void onRead(IOEvent<Context> ioEvent) {
                 // New message come
                 SelectionKey connectedKey =
ioEvent.attachment().getSelectionKey();
                 SelectorHandler selectorHandler =
ioEvent.attachment().getSelectorHandler();

                 tcpConnector.read(readPacketBuffer, false);
                 notifyParserOrParseHere();
                 selectorHandler.register(connectedKey,
SelectionKey.OP_READ);
             }

             public void onWrite(IOEvent<Context> ioEvent) {
                 // Continue async write, if wasn't completed
                 tcpConnector.write(writePacketBuffer, false);
             }
         });

         try {
             writePacketBuffer = createRequestPacketForProviderX();

             // if blocking is true, method will return only when
whole the message is written
             tcpConnector.write(writePacketBuffer, blocking);

             // read server's response
             tcpConnector.read(readPacketBuffer, blocking);

             // If async mode is used (blocking=false) - response will
come async way
             // and we need to make sure complete response is received
and only then
             // connection could be closed
             waitForCompleteResponse();
         } finally {
             tcpConnector.close();
         }
     }

On Mar 4, 2008, at 23:30 , Survivant wrote:

> they are not proxies.
>
> Basicaly, they received trades and parse them and save them into a
> dabatase. Some of them could send a formated message to MQSeries.
>
> The others applications are not currently corrected to the gateways.
> They(the clients) feed directly from the database.
>
>
> If I choose one of the gateways that I want to migrate, it a gateway
> that have 2-3 connections to extern providers like (YSX, Nasdaq..)
> and receive multiple requests from the clients.
>
> Like a client will connect to the server, ask for a stock's quote
> and disconnect when the quote is received. One other client will
> get a permanent connection to the gateway and act like a feed. This
> client will subscribe to a particuliar stock, and each update done
> to this stock will be send back to the client.
>
> that's the kind of application that we have.
>
> ----- Original Message ----- From: "Oleksiy Stashok" <Oleksiy.Stashok_at_Sun.COM
> >
> To: <users_at_grizzly.dev.java.net>
> Sent: Tuesday, March 04, 2008 11:34 AM
> Subject: Re: WELCOME to users_at_grizzly.dev.java.net
>
>
> Hi Sebastien,
>
>> How do I create a Basic server (like your echoserver) that will
>> accept multiples connections made from non NIO clients (like
>> telnet) ?
> It doesn't matter. Server can work with TCP or UDP clients regardless
> the way they implemented.
>
>>
>> I will like to have the blocking and non blocking option (for our
>> legacy gateways, they wait until a timeout).
> Grizzly works currently in non-blocking mode in other words uses NIO,
> which provides better performance for bigger amount of clients and
> better scalability.
>>
>> The gateways are connected to the markets (TXS, Bloomberg..) and
>> the volumes of trades received is pretty high. My objective is to
>> create a template gateway that will received incomming connections
>> and just replace the default connector by one different depending
>> of the market feed.
> It means gateway will work as load balancer and redirect requests to
> different points depending on there loading? In other words gateway
> will work as proxy between client and target market points?
> Are you planning to parse incoming messages on server side or you just
> need to redirect them?
> I just want to understand better how gateway should process requests.
>
> In any case, think, it should be enough easy to build some proxy like
> server.
>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>>
>> Anyone can help me to start ?
>>
>> merci Sébastien
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>