Hi Alexey-
Thanks for your quick replay and your tech
blog<
http://weblogs.java.net/blog/sdo/archive/2007/12/grizzly_protoco.html>on
grizzly。
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 ?
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.
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<http://weblogs.java.net/blog/jfarcand/archive/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
>
>
>
>
>
>