directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [MINA] Unbound streams
Date Fri, 20 Jan 2006 02:04:15 GMT
Hi Jose,

2006/1/18, Jose Alberto Fernandez <jalberto@cellectivity.com>:
>
>  Hi I have been thinking about the different solutions we have for Streams
> 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 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)       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 stream content.
>
> 2)       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)       Sender commences transmition of the stream content and ends with
> <end-mark>.
>
> 4)       Receiver's filter sends all input via the InputStream instance
> until it recognizes <end-mark> and closes the stream at that point.
>
> 5)       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 too difficult to come up with
> some natural <end-mark> 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 people
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

Mime
View raw message