Hi folks,

I'd like to have some of my fileservers from p9p accessible
via TCP, but they normally only start on a unix socket.
How can I get them running on TCP ?

thx
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/

There's no explicit support for this.

If you were to add a -c option to 9pserve
to make it connect to a network address instead of
using stdin/stdout, then you could use 9pserve
to redirect the Unix postings onto TCP.

* Russ Cox swtch.com> wrote:

Hi,

* Russ Cox swtch.com> wrote:

yep, already found it out.
Seems to work fine.

BTW: I've now mounted an vacfs from Midnight Command :)
But when trying to overwrite, it causes mc to hang. Could it be
that vacfs drops certain messages instead of returning an
appropriate error ?

That would be fine, why did you decied against ?

sorry, that should be

9pserve -c unix!`namespace`/acme tcp!*!12345

i had considered not requiring the unix! once,
but i decided against it.

russ

you can run

verbose9pserve=2 vacfs ...

and you will get a lot of debugging messages on standard error.
among other things, you'll get a trace of all the 9p traffic,
and you can check whether this is true. i doubt very much
that vacfs is dropping messages, since it is a single-threaded
server with a simple

for(;;){
read request
response = handle(request);
write response
}

loop.

the fact that dial strings live in their own parallel
universe has always seemed un-plan 9-ish to me.

we don't have this problem with devices, due to convention.
if we didn't have an implicit /net, i don't think your example
would lead to any confusion.
/net/tcp!bell-labs.com!http
is pretty clearly not a normal file.

on the other hand, making dial strings special, cuts the
namespace out of how network names are constructed.
you can't create a special case in networking with bind(1).

On Sun, Jun 1, 2008 at 10:41 AM, erik quanstrom quanstro.net> wrote:

Why include the tcp path element? Name resolution should be able to
determine the best network path to the service.

-eric

because i was declaring that the connection was via tcp.
in case this is an unimportant detail to me, i could use

/net/net/bell-labs.com/http

instead. and supposing that i am connected to bell-labs.com via
(pulls something random out of a hat) xns spp only and suppsing there
is a standard socket number assigned for http over xns/spp, this would
be equivalent to

/net/spp/bell-labs.com/http

- erik

* Russ Cox swtch.com> wrote:

thx, I'll have a try.