Hello Oscar,
>
> Thanks for your quick replay and your tech blog on grizzly
It's actually from Scott :)
>
> We are designing a MMO game server which will accept thouands of
> clients.
> The connection between clients and servers are always long-connection.
>
> OK, do you mean we need extend ProtocolParser ?
If you need to perform any message parsing related stuff - then yes,
you'll need to extend ParserProtocolFilter.
> Here is my concern on the performace if we extend ProtocolParser:
> 1. One recvBuff per WorkThread, the size, say, 8K.
> 2. We need to append recvBuff to channel-associated buffer, because
> we want to deserialize the packet.The size of channel-associated
> buffer, say, 2K. ( that is, size of one logical packet isn't bigger
> than 2K).For the flexsibility, we need config the buffer as a
> dynamic ring buffer.
It's not necessary, and I would not suggest to have 2 bytebuffers, as
it means you'll need to perform copy operation, which is not good for
performance.
It's always better to operate just with 1 ByteBuffer and it's very
easy when working with ParserProtocolFilter and ProtocolParser API.
Here you can take a look at simple ProtocolParser implementation,
which uses just one single bytebuffer [1]
If you will need any help - let us know.
Thanks.
WBR,
Alexey.
[1]
http://www.nabble.com/Re%3A-Should-I-use-Context-to-store-the-clients-references---p18489743.html
>
> Anything wrong or any suggestions?
>
> Thank you again,
> -Oscar
>
>
>
>
>
> On Thu, Jul 17, 2008 at 5:19 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
> > wrote:
> Hi,
>
>
> I know the answer just on half of the question, will let Jean-
> Francois to reply on second one :)
>>
>
>> After looking at the code, I found received data was read into
>> WorkerThread-related ByteBuffer and thebuffer was cleared before
>> next reading.In other word, users, who use grizzly to develope
>> network program, need to manage the received data by themself.
> It's not completely true.
> In Grizzly we don't associate ByteBuffer with a channel BY DEFAULT.
> Which let's Grizzly better scale on bigger loads (consume less
> memory).
> But for sure if it's required, like during message parsing - we
> associate ByteBuffers with concrete channels. To be able to store
> half of message and reuse it next time, when other half will come.
> But again there is no need to perform that manipulation by hands -
> ParserProtocolFilter does it itself.
>
>
>
>
>> My question is whether grizzly provides the feature managing the
>> channel-specific buffer like what MINA provides.
>>
>> The paper 20070712_Grizzly_Architecture.pdf told us that grizzly's
>> performance was better than MINA.
>> Do you guys know what's version number of the framework the
>> benchmark test used?
>> and what resulted in the advantage?
> I'll let Jean-Francois to answer this.
>
>
> Thanks.
>
>
> WBR,
> Alexey.
>
>>
>>
>> Thank you,
>> -Oscar
>>
>>
>
>
>
>