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?
I can do some quick and dirty coding to prove the concept. How does it sound?
Sounds good.
We already have a state machine based codec but it's far from documentation. Blame me. ;)
This doesn't seem like the ideal solution...
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. ;-)
- 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.
- DML
