Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: A stream/pipe that fills only on demand... Date: Fri, 7 Nov 2014 12:27:01 +0000 (UTC) Organization: A noiseless patient Spider Lines: 36 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 7 Nov 2014 12:27:01 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="22630"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19t/pQeBAyi96FckgYRB1AkO82kRskjq9s=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:/YVe9cj3ub/UYAsmBNEBktzPGTA= Xref: csiph.com comp.lang.java.programmer:30308 On Fri, 07 Nov 2014 09:34:15 +0000, Andreas Leitgeb wrote: > Normally, when one has a pipe-stream, the pipe gets filled on one side, > till its full, and drained on the other side while data is needed. If > less data is needed, then the remaining data in the pipe is discarded. > (simplified; no nitpicking, please) > > 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. > > 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. > > Probably it's not rocket science to program it myself, but if it rings a > bell in someone, I'd appreciate hints about existing technical terms > and/or implementations. > I certainly do NOT expect you to implement it for me, and that's also > why I didn't write up a bullet-proof specificatiion :-) What are the objections to using sockets to handle what is obviously some sort of request/response pairing? Is the response particularly large? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |