From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f66.google.com ([209.85.128.66]) by ewsd; Sun May 17 20:07:28 EDT 2020 Received: by mail-wm1-f66.google.com with SMTP id w64so8344525wmg.4 for <9front@9front.org>; Sun, 17 May 2020 17:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shaposhnik-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=wTNIzqOEZZHZ9ZAbzQomf87jvMpV6GjAqVqS9h7U3n8=; b=l0zlNqlrxcHAcnS9OhEHrHCfLcFLX+iU897ABM99AqP+h6GRupKq2qYv/os6cpkF+a 5C8tOeo/fLAghAhmEZmbxHB8vG+aiABnPBnXv+71lIUQlEo/Ipuab301HDOszveY+IKi v/kkoCr7Fh1Bo4iQXc+d2eo400usITJRP+CQ5S5U/idr27jjhz2gan3vvHdw9AAirzs3 1ZnRHqYJDmfxrSI6XIaMxU0JyhkUQh2PQu1x6WwzVcMctUwx+fbsELyn24+F8LhX2wbn AVoXewBDZrw9pw3Y4E+os+2ZCv/fywkFkxvt8OUuJsMECgPNGZ+deCpg4UPObHwb8ln6 74aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=wTNIzqOEZZHZ9ZAbzQomf87jvMpV6GjAqVqS9h7U3n8=; b=bUzgCS3OXbiDv8fXDTZRZzvnKLSDg33s52NKs9MMPZElM6leLj3cwOFjr9WTEJMeGq lGC5FWJgvVjOVPp3KKwl6h3f1M7t1jvzK8ovJPrBrhkVOX7ZqvLDbje3TYwtQthOGn5F MUmL+tXBn/oSHx3oHkco0PM8TtI6iuERLpzEDMwJL/PNrobRJJTdR2CHMepmY2q5QuqZ xL/qLpcWG/CBQMEfnk2a4yiykFKXHGijJm1QGPv09uZ1huXjYSZjY4AstV/SwqkWyyxM ksHx/miwmmi0ddyCJExsKSCVd+BA4026EjVX01RRNPKcWSM2GydpoMvVjgiWiJLfndPt Wutg== X-Gm-Message-State: AOAM533Fm6RT6+octIdB0CFMwkgqWMK8CPW+OgApA/8ip6lIej18qpzy 1nAwBJb6r+b/KAcUdVlYCPSYqStopVmK7lTtO8Oa/YSf X-Google-Smtp-Source: ABdhPJw5GjD75VA6KA6md0U8wzRgEUUlNiF1R18UUryBRdrufWJRsUkEROlLo+Wsnr7LdtpGeR6hca4KIlpdygzcP1c= X-Received: by 2002:a1c:9e43:: with SMTP id h64mr16065358wme.0.1589760444097; Sun, 17 May 2020 17:07:24 -0700 (PDT) MIME-Version: 1.0 References: <2DE413B1-B05D-45EF-A08A-6F9F119FB745@cpan.org> <436A949A-4A55-4F46-936B-F369038CCB47@cpan.org> <133678F3-1EA1-446D-9313-F10F23C84936@cpan.org> In-Reply-To: <133678F3-1EA1-446D-9313-F10F23C84936@cpan.org> From: Roman Shaposhnik Date: Sun, 17 May 2020 17:07:13 -0700 Message-ID: Subject: Re: 9P2000.s vs 9P2020 vs. ? (Was Re: [9front] Slow cp, support for 9P2000.s) To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: map/reduce replication-aware HTTP over WEB2.0 core out-scaling optimizer On Wed, May 13, 2020 at 1:27 AM Romano wrote: > > Since there's no existing discussion I can see, and IRC isn't meant for s= earching for answers to questions, is there anyone willing to summarize the= state of solving problems like streaming for 9P? > > If Aiju remembers correctly, there were two things where 9P2000.s was fou= nd wanting: > 1) it breaks the syscall interface; and > 2) it forces 9P to run over TCP. > > FWIW, I finally finished reading through all of John's thesis, rather tha= n just skimming, and I think John did a nice review of the previous work do= ne in this area and presenting why he chose the solution he did. His solut= ion used TCP, but from his write-up, I don't see a technical reason why ano= ther transport protocol[1] could not be used. That would leave only breakin= g the syscall interface. Any chance to see a link to John's thesis? > Does breaking the syscall interface mean that it's merely adding a syscal= l? Or does it mean something else? > > Right now hget(1) is an rc script that uses webfs(4). So if I'm at a ter= minal far away and am using webfs provided by the server I'm connected to, = hget would be slow for a large file because the file would be transferred o= ver 9P. It's no better than Plan 9's implementation, but no worse either. > > [1] https://en.wikipedia.org/wiki/Category:Transport_layer_protocols