Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 86106 invoked from network); 20 Jan 2006 02:04:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Jan 2006 02:04:41 -0000 Received: (qmail 3262 invoked by uid 500); 20 Jan 2006 02:04:39 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 3220 invoked by uid 500); 20 Jan 2006 02:04:39 -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 3209 invoked by uid 99); 20 Jan 2006 02:04:39 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jan 2006 18:04:39 -0800 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 66.249.92.201 as permitted sender) Received: from [66.249.92.201] (HELO uproxy.gmail.com) (66.249.92.201) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jan 2006 18:04:37 -0800 Received: by uproxy.gmail.com with SMTP id s2so152731uge for ; Thu, 19 Jan 2006 18:04:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=qFZjx0bcO6kTs545u1msIutjrlRpyihm8EvDrtiLuvCctqXZ1qHr8rmmKXiD6w0/Httiexe4tleyVtHN1rxWZMMZiYWp6kbaoP9CuuCZWAzx8HDdXA4Y91JLmZPWOhXprVE38Zfc4iWJ5dUWxohstliMSzLzvtv9f5ymBgTBw3Q= Received: by 10.49.10.20 with SMTP id n20mr102512nfi; Thu, 19 Jan 2006 18:04:15 -0800 (PST) Received: by 10.49.19.20 with HTTP; Thu, 19 Jan 2006 18:04:15 -0800 (PST) Message-ID: <768dcb2e0601191804v4a2edacp@mail.gmail.com> Date: Fri, 20 Jan 2006 11:04:15 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [MINA] Unbound streams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_141_259583.1137722655540" References: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_141_259583.1137722655540 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Jose, 2006/1/18, Jose Alberto Fernandez : > > Hi I have been thinking about the different solutions we have for Stream= s > and really none of them really convince me. > > They all require that one pre-computes the size of the stream before you > send anything, which means in most cases in memory buffering. This means > that for example, to send a Serialized object, one need to serialize it i= nto > a buffer and then send it prefixed by the size. > > > > One alternative to this would be to define a small protocol that can be > used to encapsulate an unbound stream in the middle of a transmission. > Something like: > > > > 1) Sender transmits as part of its protocol a > BEGIN_STREAM() header. is a sequence guaranteed not = to > be part of the following stream content. > > 2) Receiver has installed a filter that detects the BEGIN_STREAM > header and provides the receiver with an InputStream instance to be consu= med > (by a separate thread, perhaps). > > 3) Sender commences transmition of the stream content and ends with > . > > 4) Receiver's filter sends all input via the InputStream instance > until it recognizes and closes the stream at that point. > > 5) Any further inputs sent/received will be processed in the regula= r > manner. > > > > You can see this is inspired on UNIX's "<< EOF" shell syntax. This will > allow us to use, for example, regular object serialization without the ne= ed > for buffering. I do not think it should be too difficult to come up with > some natural given the particular nature of the stream. > > > > What do you all think? How feasible is to do this in MINA? > Sure. You can do that by implementing a state machine in your decoder. You'll have to remember which field in a message you're reading now, and reset the status when you reach the EOM (End of Message). The reason peopl= e uses prefixed data structure is because it is very easy to implement. :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ PGP Key ID: 0x854B996C ------=_Part_141_259583.1137722655540 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Jose,

2006/1/18, Jose Alberto Fe= rnandez <jalberto@cellectiv= ity.com>:

Hi I have been thinking about the different solutions we have for Streams and really none of them really convince me.<= /p>
They all require that one pre-computes the size of the stream before you send anything, which means in most cases in memory buffer= ing. This means that for example, to send a Serialized object, one need to seria= lize it into a buffer and then send it prefixed by the size.

One alternative to this would be to define a small protocol that can be used to encapsulate an unbound stream in the middle of a transmission. Something like:

1)     &n= bsp; Sender transmits as part of its protocol a BEGIN_STREAM(<end-mark>) header. <end-mark> is a sequence guaranteed not to be part of the following s= tream content.

2)     &n= bsp; Receiver has installed a filter that detects the BEGIN_STREAM header and provides the receiver with an InputStream instance to be consumed (by a separate thread, perhaps).

3)     &n= bsp; Sender commences transmition of the stream content and ends with <end-mark>.=

4)     &n= bsp; Receiver's filter sends all input via the InputStream instance until it recognizes <end-mark> and closes the stream at that point.

5)     &n= bsp; Any further inputs sent/received will be processed in the regular manner.

You can see this is inspired on UNIX's "<< EOF" shell syntax. This will allow us to use, for example, regular object serialization without the need for buffering. I do not think it should be t= oo difficult to come up with some natural <end-mark> given the particular nature o= f the stream.

What do you all think? How feasible is to do this in MINA?

Sure. You can do that by im= plementing a state machine in your decoder. You'll have to remember w= hich field in a message you're reading now, and reset the status when you r= each the EOM (End of Message). The reason people uses prefixed data s= tructure is because it is very easy to implement. :)

HTH,
Trustin

--
what we call human nature is = actually human habit
--
http://gle= amynode.net/
PGP Key ID: 0x854B996C ------=_Part_141_259583.1137722655540--