Re: [9fans] πp

[dorin bumbu <bumbudorin@gmail.com>]

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.  but keep in mind the
> server may process them in any order, so whenever
> you can't have dependencies between outstanding
> requests.  servers can only respond to the requests
> issued by the client.  in high latency cases (eg the
> network latency is > than the time it takes to service
> the request) the concurrency of the server might not
> be very important.
>
> - erik
>
>

so the real problem is not 9p itself than the transport protocol: TCP/IP.
i think that a solution might be to run 9p over an information
dispersal based protocol, to eliminate roundtrips but guaranteeing
reliability.
in this case if the server is concurrent, the effect of latency will
be almost a constant delay in response.
also an isochronous mode will not be necessary anymore, because the
protocol itself would be "isochronous".

Dorin

P.S. if there isn't implemented such a protocol, i think this will be
the way to implement 9p over UDP. i saw that in inferno there is
implemented a ida algorithm in ida(2), maybe this can be taken as a
reference.