From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 16 Oct 2010 00:13:02 +0300 Message-ID: From: dorin bumbu 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] =?iso-8859-7?q?=F0p?= Topicbox-Message-UUID: 676b9838-ead6-11e9-9d60-3106f5b1d025 2010/10/15 erik quanstrom : >> 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. =A0but keep in mind the > server may process them in any order, so whenever > you can't have dependencies between outstanding > requests. =A0servers can only respond to the requests > issued by the client. =A0in 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.