From mboxrd@z Thu Jan 1 00:00:00 1970 References: <319CCC8A-7CC8-4814-8608-FFFA624C04FD@gmail.com> <96B1444A-B40A-4F42-A387-1129C87D1387@gmail.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <36690C89-48E9-4DA3-8C47-426756A2F819@gmail.com> Content-Transfer-Encoding: 7bit From: Nemo Date: Mon, 21 Feb 2011 19:53:30 +0100 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] streams Topicbox-Message-UUID: b2a23d02-ead6-11e9-9d60-3106f5b1d025 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. thanks for your reply, Russ, btw. On Feb 21, 2011, at 12:25 AM, Nemo wrote: > >> i did read it before asking, and i'm still wondering why >> not mux tcp instead (provided you dont want/need that extra feature >> or dont implement it that way) >> >> >> On Feb 20, 2011, at 10:59 PM, Russ Cox wrote: >> >>> On Sun, Feb 20, 2011 at 11:55 AM, Nemo wrote: >>>> why not mux tcp instead? >>> >>> See the paper. Among other things, independent flow control >>> on the different sub-streams. >>> >>> http://www.brynosaurus.com/pub/net/sst-abs.html