directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [mina] Added more methods to ByteBuffer.
Date Tue, 29 Nov 2005 00:57:14 GMT
Hi Kaspar,

2005/11/29, Kaspar L├╝thi <>:
> Trustin Lee wrote:
> >
> > * getPascalString() and putPascalString() - now you can read and write
> one
> > of the most popular string encoding in networking.
> ehm, as far as i know and read, the length of a pascal string is normally
> defined in a single byte, not two.

Oops, I have to change the name.  Any suggestion considering your additional
idea (i.e. padding and variable length field length)?

maybe you could overload the PascalString-methods with a parameter,
> which defines the length (number of bytes) of the length-header?
> the padding-thing might be to special to add to mina, but i wouldn't avoid
> using it if it's there :) could be a second parameter with a boolean flag
> (i.e.
> "doPadding").

Great idea.  But boolean parameter is not appropriate because the padding
can be four bytes at max in some protocols.

initially i wanted to convert all ByteBuffer to minas-ByteBuffer, but
> without
> duplicate() i can't see how.
> it's some kind of chat-server, so the server typically receives a message
> from a
> user and forwards it to all members in the same chat-group.
> that's where i thought, the duplicate()-method fits perfectly, since it
> does
> not copy the data itself but only creates private limit/capacity/position
> for
> the copy.

It is extremely hard to implement because MINA ByteBuffer has a reference
count field in itself.  So if we duplicate the buffer, it is hard to track
the acquirement and release of the reference count.  I don't know it is even
possible.  That's why I removed duplicate() method from MINA ByteBuffer.

i actually don't have a big idea how the mina-ByteBuffer works, but i
> assume,
> that session.write() does make a copy of the data, when wrapping the
> native
> buffer.

MINA ByteBuffer.wrap() doesn't copy the data, but the created buffer is not
go to the buffer pool when it is released by default.  You can let it go to
the pool by setting 'pooled' property, but it can cause memory leak, so you
have to be careful.

i actually don't see the difficulty of implementing duplicate() - can't you
> just
> increase the aquisition-counter in the pool, when duplicating?

No.  Things get really complex if user sets 'AutoExpand' property.  then the
internal reference to NIO buffer can change at any time.  Duplicated buffers
have to track this change in real time, and it will be a lot of overhead.

ok, this might be naive (haven't used java between jdk1.2 and jdk1.5...),
> and
> duplicate() is not necessary at all using the pooled mina-ByteBuffer. if
> this
> is the
> case, i would be glad, to have some short explanation why my assumptions
> are
> wrong.

Copying costs.  But we cannot implement duplicate method easily.  It would
be great if you have any good idea. :)


the server i made using mina, is live since 2 weeks with 0.9 snapshot. we
> serve about max. 600 concurrent users. haven't had any problem since.
> great
> work guys. for me it means a big relief from my own NIO-related troubles.

That's great!  :)
what we call human nature is actually human habit

View raw message