streaming 9p

streaming 9p

[Andreas Wagner]

How about using streaming 9p in 9front? It addresses the performance
problem that seems to have in part lead to the more unix style pkg(1).

http://5e.iwp9.org/slides/floren.pdf

https://bitbucket.org/floren/tstream/overview

- AndreasBWagner

Re: streaming 9p

[Uriel]

If this streaming-9p stuff is what I remember from a while ago, which
I have been trying to erase from my brains ever since:

It completely breaks the 9P and Plan 9 model namespaces and network
transparency, please keep that idiotic crap as far away as possible.

It is an utterly disgraceful hack that destroys most of the things
that make 9P and Plan 9 awesome.

Hint: Pretending that all networks do TCP is as bad or worse than
pretending the whole world is a VAX.

If you are going to do this kind of crap, you could just as well use HTTP.

uriel

On Tue, Jun 28, 2011 at 9:51 PM, Andreas Wagner
<andreasbwagner@gmail.com> wrote:
> How about using streaming 9p in 9front? It addresses the performance
> problem that seems to have in part lead to the more unix style pkg(1).
>
> http://5e.iwp9.org/slides/floren.pdf
>
> https://bitbucket.org/floren/tstream/overview
>
> - AndreasBWagner
>

Re: streaming 9p

[Andreas Wagner]

You make a good point about tstream removing important parts of 9p.

On another topic, I am looking into implementing ccn for 9front.
(Content-Centric|Named-Data) Networking could fit the plan9 model like
a glove. I just need to finish all my plan9 and ccnx readings so that
I can do it tastefully and thoroughly.

Links for those who are not familiar with ccn:

http://www.named-data.net/publications.html

http://www.ccnx.org/

- AndreasBWagner

On Tue, Jun 28, 2011 at 8:21 PM, Uriel <uriel@berlinblue.org> wrote:
> If this streaming-9p stuff is what I remember from a while ago, which
> I have been trying to erase from my brains ever since:
>
> It completely breaks the 9P and Plan 9 model namespaces and network
> transparency, please keep that idiotic crap as far away as possible.
>
> It is an utterly disgraceful hack that destroys most of the things
> that make 9P and Plan 9 awesome.
>
> Hint: Pretending that all networks do TCP is as bad or worse than
> pretending the whole world is a VAX.
>
> If you are going to do this kind of crap, you could just as well use HTTP.
>
> uriel
>
> On Tue, Jun 28, 2011 at 9:51 PM, Andreas Wagner
> <andreasbwagner@gmail.com> wrote:
>> How about using streaming 9p in 9front? It addresses the performance
>> problem that seems to have in part lead to the more unix style pkg(1).
>>
>> http://5e.iwp9.org/slides/floren.pdf
>>
>> https://bitbucket.org/floren/tstream/overview
>>
>> - AndreasBWagner
>>
>

Re: streaming 9p

[Ethan Grammatikidis]

On Tue, 28 Jun 2011 23:49:59 -0400
Andreas Wagner <andreasbwagner@gmail.com> wrote:

> You make a good point about tstream removing important parts of 9p.
> 
> On another topic, I am looking into implementing ccn for 9front.
> (Content-Centric|Named-Data) Networking could fit the plan9 model like
> a glove. I just need to finish all my plan9 and ccnx readings so that
> I can do it tastefully and thoroughly.
> 
> Links for those who are not familiar with ccn:
> 
> http://www.named-data.net/publications.html
> 
> http://www.ccnx.org/

Any chance you could summarize how CCN works? I started to read Jacobson.pdf but haven't got the time to read enough to discover whether it will make my eyes bleed. My first impression is it's like using torrents for everything but with some different discovery mechanism.

Perhaps more importantly (and possibly simpler), could you summarize how unique names are constructed for CCN data, please?

Re: streaming 9p

[Andreas Wagner]

> Any chance you could summarize how CCN works? I started to read Jacobson.pdf but haven't got the time to read enough to discover whether it will make my eyes bleed. My first impression is it's like using torrents for everything but with some different discovery mechanism.
>
> Perhaps more importantly (and possibly simpler), could you summarize how unique names are constructed for CCN data, please?
>

CCN does not have anything to do with bittorrent. With CCN
content/names are the primitives rather than locations/ip addresses,
in other words location is decoupled from content, identity and
access. At first it may seem that CCN is only useful for static
content, however VoCCN (Voice over CCN) exists and eliminates the need
for the middleware. Mobility is a non-issue with CCN because content
does not need to be mapped to a location. From what I can see the CCNx
implementation works on top of IP although CCN intended to replace
TCP/IP. CCN names can have a unique dns domain name prefix for
connectivity better connectivity over the internet.

An "Interest packet" is forwarded on a "face" when the prefix of its
name matches a prefix of a name in the Forwarding Information Base,
when the name of an Interest Packet satisfies (matches) the name of a
"Data packet" the data packet is forwarded downstream following the
Pending Interest Table (breadcrumb) entries. In many ways CCN is
similar to TCP/IP because the designers did not want unnecessarily to
throw out what has worked with TCP/IP.

I am looking into porting ccn to 9front for use with the filesystem
and 9p. I guess I the filesystem would be the ccn data repository and
the ccn names would be the filenames and directory paths.

Re: streaming 9p

[Ethan Grammatikidis]

On Mon, 11 Jul 2011 15:54:11 +0200
Andreas Wagner <andreasbwagner@gmail.com> wrote:

> > Any chance you could summarize how CCN works? I started to read Jacobson.pdf but haven't got the time to read enough to discover whether it will make my eyes bleed. My first impression is it's like using torrents for everything but with some different discovery mechanism.
> >
> > Perhaps more importantly (and possibly simpler), could you summarize how unique names are constructed for CCN data, please?
> >
> 
> CCN does not have anything to do with bittorrent. With CCN
> content/names are the primitives rather than locations/ip addresses,
> in other words location is decoupled from content, identity and
> access. At first it may seem that CCN is only useful for static
> content, however VoCCN (Voice over CCN) exists and eliminates the need
> for the middleware. Mobility is a non-issue with CCN because content
> does not need to be mapped to a location. From what I can see the CCNx
> implementation works on top of IP although CCN intended to replace
> TCP/IP. CCN names can have a unique dns domain name prefix for
> connectivity better connectivity over the internet.
> 
> An "Interest packet" is forwarded on a "face" when the prefix of its
> name matches a prefix of a name in the Forwarding Information Base,
> when the name of an Interest Packet satisfies (matches) the name of a
> "Data packet" the data packet is forwarded downstream following the
> Pending Interest Table (breadcrumb) entries. In many ways CCN is
> similar to TCP/IP because the designers did not want unnecessarily to
> throw out what has worked with TCP/IP.
> 
> I am looking into porting ccn to 9front for use with the filesystem
> and 9p. I guess I the filesystem would be the ccn data repository and
> the ccn names would be the filenames and directory paths.

Thanks for the summary! The implications are a bit beyond me after all, but I like the easy multicasting and the reduction of mobility issues. I can see some congestion issue with rapid mobility but I don't suppose it'll become a real problem.

Am I right in thinking you'd use something like "host/pathname" as the name in CCN when you wanted to retrieve a file?

Re: streaming 9p

[Julius Schmidt]

> If this streaming-9p stuff is what I remember from a while ago, which
> I have been trying to erase from my brains ever since:
>
> It completely breaks the 9P and Plan 9 model namespaces and network
> transparency, please keep that idiotic crap as far away as possible.
>
> It is an utterly disgraceful hack that destroys most of the things
> that make 9P and Plan 9 awesome.
>
> Hint: Pretending that all networks do TCP is as bad or worse than
> pretending the whole world is a VAX.
>
> If you are going to do this kind of crap, you could just as well use HTTP.

Amen.
It's even worse than pretending every network is TCP.
A motherfucking *SYSCALL* for hurr durr performance in some special
cases.
If you want 9P to behave like HTTP, use HTTP, really.
A much better idea than breaking everything and adding even more syscalls.
What has he been smoking?

aiju

Re: streaming 9p

[Ethan Grammatikidis]

On Wed, 29 Jun 2011 02:21:38 +0200
Uriel <uriel@berlinblue.org> wrote:

> If this streaming-9p stuff is what I remember from a while ago, which
> I have been trying to erase from my brains ever since:
> 
> It completely breaks the 9P and Plan 9 model namespaces and network
> transparency, please keep that idiotic crap as far away as possible.

Wasn't pipelining a better idea to the same end, and doesn't 9p have pipelining support already, but the fileservers don't generally implement it? If so, perhaps we should write pipeline support into the fileservers, particularly those we most want to share over long distance networks: the actual file storage FSs. There aren't too many of them.