From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <36690C89-48E9-4DA3-8C47-426756A2F819@gmail.com> References: <319CCC8A-7CC8-4814-8608-FFFA624C04FD@gmail.com> <96B1444A-B40A-4F42-A387-1129C87D1387@gmail.com> <36690C89-48E9-4DA3-8C47-426756A2F819@gmail.com> Date: Tue, 22 Feb 2011 10:15:39 +0000 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] streams Topicbox-Message-UUID: b2b98e4e-ead6-11e9-9d60-3106f5b1d025 On 21 February 2011 18:53, Nemo wrote: > i reply myself; i think they use sst to mix multimedia streams, and > in that case a lost packet in one stream (say text) would > delay other streams (say audio) that do not need to be delayed if > you use sst. > > But otherwise I still think that muxing a tcp stream might provide > something similar (without some of sst ffeatures, i admit) and a lot > easier to implement. I'll write a toy to see if this is wrong. i've been playing around with something similar in Go, layering rpc (analogous to 9p) over netchan (analogous to SST), which seems to work quite well, although i haven't done many performance experiments. this by itself doesn't entirely mitigate 9p performance though. there are many sequences of operations that still require multiple unnecessary round trips. i've also been experimenting with a 9p modification that suggested some while ago, allowing multiple outstanding requests to be queued in sequence. it works, but the code still needs quite a bit of polishing. the summary is here: http://code.google.com/p/rog-go/source/browse/new9p/doc.txt