Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 70647 invoked from network); 13 Jan 2006 00:48:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jan 2006 00:48:37 -0000 Received: (qmail 55441 invoked by uid 500); 13 Jan 2006 00:48:36 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 55392 invoked by uid 500); 13 Jan 2006 00:48:36 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 55381 invoked by uid 99); 13 Jan 2006 00:48:36 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jan 2006 16:48:36 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 66.249.92.198 as permitted sender) Received: from [66.249.92.198] (HELO uproxy.gmail.com) (66.249.92.198) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jan 2006 16:48:33 -0800 Received: by uproxy.gmail.com with SMTP id s2so121543uge for ; Thu, 12 Jan 2006 16:48:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dmdiEEfXzU538RPzZkzC6ZaF062FsY7asf67xni+zvWkcDCEM1RQO07zPqMCTCyXy+8FKcDBOtaAg6xf8jM5KB3R1O3iLkCNs/WHaBYmTwgy9wBibBSB9clh/mVVF1xaQaYBM76rMPzZevG+V17q+DtIP6E5OZYNuZTrbGJ5kuo= Received: by 10.48.202.20 with SMTP id z20mr31502nff; Thu, 12 Jan 2006 16:48:10 -0800 (PST) Received: by 10.49.19.20 with HTTP; Thu, 12 Jan 2006 16:48:10 -0800 (PST) Message-ID: <768dcb2e0601121648jb798706x@mail.gmail.com> Date: Fri, 13 Jan 2006 09:48:10 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: direct access to sockets Cc: Johannes Zillmann In-Reply-To: <43BECCD3.4020601@yahoo.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7475_7911730.1137113290785" References: <43B1044D.7060107@eurone.it> <43B11B5F.3020303@trillian.se> <43B1233C.6060000@eurone.it> <43B12FBD.1030407@trillian.se> <43B1451F.4020308@eurone.it> <43B14BE3.5080009@trillian.se> <43B14F0C.1000306@eurone.it> <43BECCD3.4020601@yahoo.de> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_7475_7911730.1137113290785 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Johannes, 2006/1/7, Johannes Zillmann : > > Dear mina team, > > currently i'm participate in 2 projects in which network communication > plays a big role. > The profile of the projects looks similar: > - there is a lot of coordination communication to do, whereat mina is > great > - but a lot of large data blocks(simply call it files..) has to be moved > as well, whereat mina naturally can't beat fe a simple bio socket > implementation in performance > > After testing a lot and thinking some time about it, i came to the point > that the simplest way to gain the efforts of using > mina but not loosing any piece of performance is to have the possibilty > to get direct access to a sessions socket (no matter if bio or nio). > > This would avoid the overhead of chunking, filtering,... data which is > not intended to do so. > And it would allow things like > FileChannel fc; > SocketChannel sc; > fc.transferFrom(sc,0,23); For now there's no way to achieve the same behavior with this. But I guess we can implement this by providing a special write request object: IoSession session =3D ...; session.write( new TransferRequest( fc, 0, 23 ) ); WDYT? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ PGP Key ID: 0x854B996C ------=_Part_7475_7911730.1137113290785 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Johannes,

2006/1/7, Johannes Zil= lmann <JZ8_blue@yahoo.de>:
Dear mina team,

currently i'm participate in 2 projects in which net= work communication
plays a big role.
The profile of the projects look= s similar:
- there is a lot of coordination communication to do, whereat= mina is great
- but a lot of large data blocks(simply call it files..) has to be move= d
as well, whereat mina naturally can't beat fe a simple bio socket
i= mplementation in performance

After testing a lot and thinking some t= ime about it, i came to the point
that the simplest way to gain the efforts of using
mina but not loos= ing any piece of performance is to have the possibilty
to get direct acc= ess to a sessions socket (no matter if bio or nio).

This would avoid= the overhead of chunking, filtering,... data which is
not intended to do so.
And it would allow things like
FileChannel= fc;
SocketChannel sc;
fc.transferFrom(sc,0,23);
For now there's no way to achieve the same behavior with this.  But I= guess we can implement this by providing a special write request object:

IoSession session =3D ...;
session.write( new TransferRequest( f= c, 0, 23 ) );

WDYT?

Trustin
--
what we call hu= man nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C ------=_Part_7475_7911730.1137113290785--