From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <d9d43a1aa634a5ef999566df7a7db0e7@plug.quanstro.net>
References: <AANLkTimvaNcf3hC8gPAXrFDDs3CKH2ZVa4siS_ihCQvx@mail.gmail.com>
	<AANLkTikCoXwEp=d6D4uCsU1pOBr=N-rFQARBPj7p_Qb7@mail.gmail.com>
	<AANLkTimZS1jvvGrtzxZhS=iM4rkje1t=PbYL-rCN1cEO@mail.gmail.com>
	<AANLkTinmSbZkCUE874O82Dt=gJaooET+s3_XVyZ_w82_@mail.gmail.com>
	<AANLkTin3O=va2Msv+3r96PKQjrSQqX5EuReh8k9PRdfC@mail.gmail.com>
	<AANLkTi=yCrhS3byca+R3b3-srOrdAHe7UQtVWHkvLJ-A@mail.gmail.com>
	<cd070e8e56994d301a7af213b53f031d@plug.quanstro.net>
	<AANLkTikFvDW4DUkFhP-2ffR1EXaJKzcVf8xnjWE4oQtC@mail.gmail.com>
	<d9d43a1aa634a5ef999566df7a7db0e7@plug.quanstro.net>
Date: Sat, 16 Oct 2010 02:30:42 +0300
Message-ID: <AANLkTimWAOTVXkONNbM-fFXt-NjeAuM2gNS059nFBVVw@mail.gmail.com>
From: dorin bumbu <bumbudorin@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [9fans] =?iso-8859-7?q?=F0p?=
Topicbox-Message-UUID: 67b2a200-ead6-11e9-9d60-3106f5b1d025

2010/10/16 erik quanstrom <quanstro@quanstro.net>:
> On Fri Oct 15 17:14:18 EDT 2010, bumbudorin@gmail.com wrote:
>> 2010/10/15 erik quanstrom <quanstro@quanstro.net>:
>> >> isn't tag field for this intended?
>> >
>> > [...]
>> >
>> >> so this means to me that a client can send some T-messages and then
>> >> (or concurrently) wait the R-messages.
>> >> in inferno from mount(1) and styxmon(8) i deduced that this case is
>> >> also considered.
>> >> it's true that most of the servers i seen until now doesn't take
>> >> advantage of this feature, they respond to each T-message before
>> >> processing next message.
>> >
>> > there is no defined limit to the number of
>> > outstanding tags allowed. [...]
>>
>> so the real problem is not 9p itself than the transport protocol: TCP/IP.
>
> the transport has nothing to do with it;


consider the following (imaginary) example:

let say that i want to watch a live videocast, and i am in kiev and
the video is emitted from seattle as a 9p service.
i'll mount that service in my local namespace, and my imaginary video
player istead of processig 9p messages in traditional way:
[...] TRead -> RRead -> TRead -> RRead -> TRead -> [...]

will have one thread that:  [...] TRead -> TRead-> TRead->
TRead->TRead->TRead -> [...]
and another one that :      [...]  <--     t0      -->RRead -> RRead->
RRead -> RRead-> RRead-> RRead-> [...]


if transport protocol hasn't anything to do with, please explain me
what other drawbacks will be involved other than a t0 delay, if
latency would be constant?

>
>> i think that a solution might be to run 9p over an information
>> dispersal based protocol, to eliminate roundtrips but guaranteeing
>> reliability.
>
> the definitiion of 9p relies on having round trips.

i was reffering on TCP/IP's roundtrips for each package confirmation,
and not to eliminate 9p's round trips.
in 9p case i suggested to process some of them as i wrote on previous
lines, when high data traffic is involved, like in video streaming.

>
> - erik
>
>