Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nigel Wade Newsgroups: comp.lang.java.programmer Subject: Re: A stream/pipe that fills only on demand... Date: Mon, 10 Nov 2014 09:24:31 +0000 Lines: 30 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net C9Vfrxi/B6ZoMYCwfxasoQr1tMSOVPjvKaib7MTm8YlCJskcIJ Cancel-Lock: sha1:FV87ZUL6s1D44dRR4psqWpPI8fI= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:30327 On 07/11/14 09:34, Andreas Leitgeb wrote: > My needs are a bit different, though: I need a pipe-stream > that recognizes reader's request for bytes, and tells the > writer-end about the requested volume, and then the writer > will write just as much into the pipe as is needed by the > reader. The reader just uses the normal API that InputStream > offers, but I need these calls to identify themselves to the > pipe-writer, which would use a (yet unspecified) special API, > so the writer knows how much to put into the pipe-stream. That's one scenario, but it's not the only one. What you are essentially describing is a read request, write response. The reader sends a request to the writer telling it what it wants and the writer sends a response which the reader can read. > > Background is, that the items that the writer will put into > the pipe-stream are "precious" and must not be wasted. > Kind of like reading back a stream of serialized data, where > each de-serializing object must not consume more than its own > bytes, but the Object needing its data is on a different host > than the byte stream. That's just an analogy - don't stress it. When I need to do something similar I use either GenericServlet or RMI. Normally servlet for inter-host and RMI for inter-process, but there's no reason why you can't use either approach for either solution. Both of them are suitable for request/response operations. RMI has less overhead because it doesn't require a servlet engine, just the rmiregistry.