2010/10/16 erik quanstrom <quans...@quanstro.net>: > On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote: >> 2010/10/15 erik quanstrom <quans...@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 > >
