From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <90e9f70b35a4d82d4287fee617a89392@isd.dp.ua> References: <58c8e88cdc5afad38233c3ab4bb74344@quanstro.net> <90e9f70b35a4d82d4287fee617a89392@isd.dp.ua> Date: Mon, 31 Aug 2009 09:27:11 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9P/Styx: streaming / contigious reading Topicbox-Message-UUID: 5d166530-ead5-11e9-9d60-3106f5b1d025 Was waiting for someone else to say it, but you should look at what Octopus does with its operation continuation flags. Another interesting twist on this is "lossy" streams -- but such a thing may be best represented outside of 9P (or perhaps with a 9P gateway). -eric On Mon, Aug 31, 2009 at 9:20 AM, yaroslav wrote: >> > > did anyone already investigate how an streaming (w/o expicit read >> > > requests) could be done via 9P ? >> > >> > Why don't you use a protocol more suitable for high latencies? >> >> i think the problem rather is the tradition of having one >> outstanding message per fid. =A0as far as i can tell, 9p doesn't >> have this restriction. =A0we just use it that way. > > Maybe the way fcp(1) works is the answer? > > -- Yaroslav > > >