From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6d8e09991be97d61af9b495b8d56686f@gmx.de> To: 9fans@9fans.net Date: Sat, 16 Oct 2010 01:45:49 +0200 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-abcrtxshvlltjusluktlebwlkf" Subject: Re: [9fans] =?utf-8?b?z4Bw?= Topicbox-Message-UUID: 67b8da8a-ead6-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-abcrtxshvlltjusluktlebwlkf Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit when you are in kiev, video streams YOU! -- cinap --upas-abcrtxshvlltjusluktlebwlkf Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 15 Oct 2010 23:35:09 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx024) with SMTP; 16 Oct 2010 01:35:09 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1P6tjg-0006ry-J3; Fri, 15 Oct 2010 23:30:52 +0000 Received: from mail-vw0-f49.google.com ([209.85.212.49]) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1P6tje-0006rq-LF for 9fans@9fans.net; Fri, 15 Oct 2010 23:30:50 +0000 Received: by vws5 with SMTP id 5so599699vws.36 for <9fans@9fans.net>; Fri, 15 Oct 2010 16:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=+e7qvQQP1o4nnw7AF1EU3S/FpR4GCyyp2X5f7svBw+k=; b=Cysm96FnhMltVgE7OCdPOq9t01q+tt7s+vvC+raGOOSa5ooH7t3uq8CRlIIcn0Jm5c 4xLeP/WOkLmpkrF7e3jAgsBa8OxGS11M+WXmSiIBpqiouNDOub/NAaXQSqneENOPzIcx tYC7G6nBv+4KcbG1iqCmwhm+YQ5D5HiwRlyVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dILHd8/gjsQ8Im3s2NHQh7kOv4/1OoRpLW6GSByrLxZgzsO4gNSuZDnXlbY3dIarwU hHgJ4hxe/ZSxddlU5Fb69iA/sI5bYHUdL3d/EwHHSL7EdQmMDJap8XA6Sc1V70xZhaqz r4YHvVjWAS1fb4nKpb6ycwHhJSIFvVi0dmHGg= MIME-Version: 1.0 Received: by 10.220.85.19 with SMTP id m19mr127906vcl.77.1287185442654; Fri, 15 Oct 2010 16:30:42 -0700 (PDT) Received: by 10.220.201.139 with HTTP; Fri, 15 Oct 2010 16:30:42 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Oct 2010 02:30:42 +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 Subject: Re: [9fans] =?iso-8859-7?q?=F0p?= X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p4U4jfdfC5HDevlx1X2sAZg1MkugZcpwIdDb8z5l6KEaP+LdZ7QLw+5CKzyp k5HTLZ1v8wPRqFdQdQapWq9qz59Rr52fCiljKsM85i3sbXAJVBjnzZkoSL42zBmmwDa5vja6zT3o 7boow==V1; 2010/10/16 erik quanstrom : > On Fri Oct 15 17:14:18 EDT 2010, bumbudorin@gmail.com wrote: >> 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. [...] >> >> 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 > > --upas-abcrtxshvlltjusluktlebwlkf--