Hi Yuriy, MINA doesn't make any assumption when it reads data from a socket, and therefore it doesn't know how to split the read data into multiple parts when it reads the data. That's what protocol codec layer does in MINA. This separation of concern leads to better flexible application design.
To avoid copying a whole message into multiple buffers, you can use IoBuffer.slice() operation which doesn't require copy. For gathering write, please refer to the following issue: https://issues.apache.org/jira/browse/DIRMINA-518 It's just impractical to use gathering write just for now. Hopefully newer releases of JDK will implement gathering write correctly, and then MINA will be improved to support gathering write transparently maintaining backward compatibility. HTH, On Thu, 2008-03-27 at 00:00 +0900, Yuriy Cherniavsky wrote: > Hi MINA community. > > During analyzing of most famous NIO frameworks I notice that it does not > provide the possibility to use read(ByteBuffer[] dsts)/write(ByteBuffer[] > srcs) or read(ByteBuffer[] dsts, int offset, int length)/write(ByteBuffer[] > srcs, int offset, int length) methods of java.nio.channels.DatagramChannel > or java.nio.channels.SocketChannel classes. > > I look deeper in source code of sun jdk1.6 (JNI part) and saw that this > methods implements by OS function (recvmsg/sendmsg on Linux/Solaris and > WSARecv/WSASend on Windows). So it will improve the performance in such task > as mine - some type of data proxy. > Target: process UDP package with some my fixed size protocol header + raw > data, and if I can use read(ByteBuffer[] dsts)/write(ByteBuffer[] srcs) > methods, I will pass arrays of two ByteBuffer for read and write. Where > first ByteBuffer (fixed size protocol header) will process for proxy > functionality and second ByteBuffer (raw data) must not wanted any process > and even copy (only flip or rewind if needed)! > > What are you think about such functionality? Cat it be added to MINA > framework? > Or if such functionality already exist how can I use it? > > Truly yours, Yuriy. > > > > __________ Information from ESET Smart Security, version of virus signature > database 2974 (20080326) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
