David M. Lloyd wrote: > On 04/28/2008 11:39 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote: >> I'd prefer to introduce an interface type because ByteBuffer is >> impossible to extend. > > That's fair, but I don't see why you'd need to extend ByteBuffer anyway?
Because we can't create a Composite ByteBuffer by extending ByteBuffer.
ByteBuffer also has unnecessary stuff like position, mark, limit,
flip(), compact() and order() which changes the state and behavior of
the buffer. There's no way to make the position and limit read-only
while making the buffer content writable.
>> I can do some quick and dirty coding to prove the concept. How does
>> it sound?
>
> Sounds good.
Great. Let me come up with some working code tomorrow.
>> My long term idea is to write something similar to ANTLR (parser
>> generator) which works in a binary level; we can call it decoder
>> generator.
>
> This would be better. ;-)
Yeah. The only problem is all nice parser generator implementations
depend on InputStream and consequently blocking I/O. We need to write a
new generator which works with non-blocking I/O.
>>>> - how to write an efficient encoder when you have no idea about the
>>>> size of the data you are going to send ?
>>> Use a buffer factory, such as IoBufferAllocator, or use an even simpler
>>> interface like this:
>>>
>>> public interface BufferFactory {
>>> ByteBuffer createBuffer();
>>> }
>>>
>>> which mass-produces pre-sized buffers. In the case of stream-oriented
>>> systems like TCP or serial, you could probably send buffers as you fill
>>> them. For message-oriented protocols like UDP, you can accumulate all
>>> the buffers to send, and then use a single gathering write to send them
>>> as a single message (yes, this stinks in the current NIO implementation,
>>> as Trustin pointed out in DIRMINA-518, but it's no worse than the
>>> repeated copying that auto-expanding buffers use; and APR and other
>>> possible backends [and, if I have any say at all in it, future OpenJDK
>>> implementations] would hopefully not suffer from this limitation).
>>
>> Allocating a pre-sized buffer per connection can cause OOM when there
>> are massive number of idle connections.
>
> I don't mean to allocate a buffer per connection, I mean to allocate
> buffers as needed. An idle connection should need no buffers, if the
> codec is efficiently implemented.
An efficient buffer class is needed to implement an efficient codec IMO.
We could probably start from the low-level buffer (or array)
implementation and see what we can do with our existing codecs?
Thanks,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
