Hi folks,
did anyone already investigate how an streaming (w/o expicit read
requests) could be done via 9P ?
An option could be adding a new opcode telling the server that it
should send RRead's contigiously, within some given some range.
(will require an ordered transport, since RRead lacks
On Aug 30, 2009, at 10:34 PM, erik quanstrom quans...@quanstro.net
wrote:
On Sun Aug 30 14:37:29 EDT 2009, rminn...@gmail.com wrote:
One way to make this kind of interesting is to address how you'd do a
reasonable zeroconf effort given that you need to boot 1m+ machines.
We've booted
I think there are a few issues beyond will it scale - of course with
128k nodes scaling is a baseline prereq for us. On BG we have a
segmented network to deal with -- but it's likely you'll want some
form of hierarchy regardless.
I have done much with dynamic service registry using
You can implement a NAT by mounting a /net from a perimeter machine
with a public IP, while connecting to it from an internal network of private
IP addresses, using the Plan 9 protocol 9P in the internal network.
This is from the wikipedia page on Plan 9 OS.
Is something like iptables like in
Why don't you use a protocol more suitable for high latencies?
On Mon, Aug 31, 2009 at 12:20 PM, Enrico Weigeltweig...@metux.de wrote:
Hi folks,
did anyone already investigate how an streaming (w/o expicit read
requests) could be done via 9P ?
An option could be adding a new opcode
On Mon Aug 31 09:00:33 EDT 2009, 23h...@googlemail.com wrote:
Why don't you use a protocol more suitable for high latencies?
i think the problem rather is the tradition of having one
outstanding message per fid. as far as i can tell, 9p doesn't
have this restriction. we just use it that way.
You can implement a NAT by mounting a /net from a perimeter machine
with a public IP, while connecting to it from an internal network of private
IP addresses, using the Plan 9 protocol 9P in the internal network.
This is from the wikipedia page on Plan 9 OS.
Is something like iptables
On Mon, Aug 31, 2009 at 7:51 AM, erik quanstromquans...@quanstro.net wrote:
could you explan why you're focused on dns?
a more natural way to use plan 9 would be to use
ndb and cs directly. wouldn't it?
Of course. My use of DNS was really just in abstract to refer to the
suite of existing
that wiki writeup isn't really right. importing /net isn't NAT in any
sort of technical sense; rather, it's what plan 9 does instead.
there's no translation of ports or addresses, it's more
(conceptually) like a straight multiplexing.
Of course. My use of DNS was really just in abstract to refer to the
suite of existing services for name and service resolution under Plan
9. However, I think the current interfaces for ndb and cs are very
limiting and the single file based query mechanisms don't really match
the
did anyone already investigate how an streaming (w/o expicit read
requests) could be done via 9P ?
Why don't you use a protocol more suitable for high latencies?
i think the problem rather is the tradition of having one
outstanding message per fid. as far as i can tell, 9p doesn't
On Mon, Aug 31, 2009 at 9:04 AM, erik quanstromquans...@quanstro.net wrote:
given the database= option, if one could confine rapid changes to
smaller files, one could teach ndb to only reread changed files.
Why not have a synthetic file system interface to ndb that allows it
to update its own
Was waiting for someone else to say it, but you should look at what
Octopus does with its operation continuation flags.
Another interesting twist on this is lossy streams -- but such a
thing may be best represented outside of 9P (or perhaps with a 9P
gateway).
-eric
On Mon, Aug 31, 2009 at
How about we convince the mailing list software to stop
inserting Reply-To headers.
please don't. it's a list, with reply to the list.
given the database= option, if one could confine rapid changes to
smaller files, one could teach ndb to only reread changed files.
Why not have a synthetic file system interface to ndb that allows it
to update its own files? I think this is my primary problem.
Granular modification
2009/8/31 Vinu Rajashekhar vinuthe...@gmail.com:
You can implement a NAT by mounting a /net from a perimeter machine
with a public IP, while connecting to it from an internal network of private
IP addresses, using the Plan 9 protocol 9P in the internal network.
This is from the wikipedia page
Hmmm. we did that for FS processes on Plan B. I mean, keep a
dynamic version of a registry. It kept the list of volumes available at a
central place.
I think it can be used as is on Plan 9, without changes.
There was a program (I think it was called adsrv; not sure, it´s on the
Plan B man pages)
On Mon, Aug 31, 2009 at 9:36 AM, erik quanstromquans...@quanstro.net wrote:
i can see in principle how this could be a good idea (no more
comments, though). could you elaborate, though. i have found
editing /lib/ndb/local works well at the scales i see.
I think the main issue with just
On Mon, Aug 31, 2009 at 8:21 PM, Devon H. O'Delldevon.od...@gmail.com wrote:
2009/8/31 Vinu Rajashekhar vinuthe...@gmail.com:
You can implement a NAT by mounting a /net from a perimeter machine
with a public IP, while connecting to it from an internal network of private
IP addresses, using the
i can see in principle how this could be a good idea (no more
comments, though). could you elaborate, though. i have found
editing /lib/ndb/local works well at the scales i see.
[...]
machines, even with multiple admins. I have a feeling it starts to
break down with thousands of
While that sounds interesting and may be useful in its own right, a
centralized server isn't really desirable -- part of the nice thing of
zeroconf is moving to a decentralized environment, and ideally doing
it in a scalable fashion (which isn't trivial on hundreds of thousands
of cores, we
On Mon, 31 Aug 2009 09:25:36 CDT Eric Van Hensbergen eri...@gmail.com wrote:
Why not have a synthetic file system interface to ndb that allows it
to update its own files? I think this is my primary problem.
Granular modification to static files is a PITA to manage -- we should
be using
On Mon, Aug 31, 2009 at 10:52 AM, erik quanstromquans...@coraid.com wrote:
so plunkers like us with a few hundred machines are just casual users?
i'd hate for plan 9 to become harder to use outside a hpc environment.
it would be good to be flexable enough to support fairly degnerate cases
On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.com wrote:
ndb maps directly to a list of lisp's association lists but
how would you map this to a synthetic fs? Something like
attr/value to yield a tuple? For example:
My current intuition in these situations is to allow for
i don't know if this is related to recent postscript
printer troubles, but i have no problems talking to
the local printer. the problem is font support.
to support fonts, gs is run to convert to a postscript
bitmap. unfortunately, gs isn't up to this task:
; bind /n/sources/plan9/386/bin/gs
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com:
But this is nasty!
% cat ndb/dom/'' # same as ndbquery dom ''
No, the nasty part is really that the file should be called `.' and
the filesystem reserves dot as the reference to the current directory.
You could probably call the file `dot'
2009/8/31 erik quanstrom quans...@coraid.com:
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com:
But this is nasty!
% cat ndb/dom/'' # same as ndbquery dom ''
No, the nasty part is really that the file should be called `.' and
the filesystem reserves dot as the reference to the current
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com:
But this is nasty!
% cat ndb/dom/'' # same as ndbquery dom ''
No, the nasty part is really that the file should be called `.' and
the filesystem reserves dot as the reference to the current directory.
You could probably call the file `dot' or
It's (in my opinion) slightly less evil because if(!strlen(name))
seems like a pretty poor way to determine that you're looking at the
root zone. It's also more intuitive and easier to document that you're
looking at the root than saying `to find root, look for a file named
as an empty
On Mon Aug 31 12:58:29 EDT 2009, quans...@coraid.com wrote:
i don't know if this is related to recent postscript
printer troubles, but i have no problems talking to
the local printer. the problem is font support.
to support fonts, gs is run to convert to a postscript
bitmap. unfortunately,
With the hopes of playing Go amongst
fellow Plan 9 users, I've written a little
filesystem[1] which can currently be
used for any two-player turn-based
games.
I'm currently working on Paurea's
wonderful goban code, to implement
support for reading from and writing to
files, so that we have a
it was too hard being lazy, so i finally put up a changelog
from the version of nupas presented at iwp9 3e in volos.
http://www.quanstro.net/plan9/changes2009.html
- erik
It might be worth the effort to implement Go Text Protocol
(http://www.lysator.liu.se/~gunnar/gtp/), just in case you're having
trouble finding people to play with.
Anyway, nice work.
fhs
2009/8/31 Akshat Kumar aku...@mail.nanosouffle.net:
With the hopes of playing Go amongst
fellow Plan 9
It might be worth the effort to implement Go Text Protocol
(http://www.lysator.liu.se/~gunnar/gtp/), just in case you're having
trouble finding people to play with.
No, I'm going for world domination. Starting with the local Go group.
The fileserver is meant for Plan 9 communications, and is
temporarly out of time on this one. it appears
from the assembly output that 8c multiplies by
0 and not 1 when computing z a second time.
nonetheless, i haven't yet seen the problem.
#include u.h
#include libc.h
void
main(void)
{
int three, one;
uvlong twelve, z;
one =
if it's my fault i'll fix it. it did screw up mod in a subtle way but
that's been fixed.
brucee
On Tue, Sep 1, 2009 at 11:47 AM, erik quanstromquans...@quanstro.net wrote:
temporarly out of time on this one. it appears
from the assembly output that 8c multiplies by
0 and not 1 when computing
temporarly out of time on this one. it appears
from the assembly output that 8c multiplies by
0 and not 1 when computing z a second time.
nonetheless, i haven't yet seen the problem.
not quite that simple.
it's a register allocation
(really register management) bug.
On Mon, Aug 31, 2009 at
37 matches
Mail list logo
