[9fans] plan9port: tcp servers

[9fans] plan9port: tcp servers

[Enrico Weigelt]

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/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] plan9port: tcp servers

[Russ Cox]

> 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 ?

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.

	ARGBEGIN{
	...
	case 'c':
		if((fd = dial(EARGF(usage()), nil, nil, nil)) < 0)
			sysfatal("dial %s: %r");
		dup(fd, 0);
		dup(fd, 1);
		if(fd > 1)
			close(fd);
		break;
	...
	}ARGEND

Then you could run something like

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

Russ

Re: [9fans] plan9port: tcp servers

[Enrico Weigelt]

* Russ Cox <rsc@swtch.com> wrote:

Hi,

> 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.
>
> 	ARGBEGIN{
> 	...
> 	case 'c':
> 		if((fd = dial(EARGF(usage()), nil, nil, nil)) < 0)
> 			sysfatal("dial %s: %r");
> 		dup(fd, 0);
> 		dup(fd, 1);
> 		if(fd > 1)
> 			close(fd);
> 		break;
> 	...
> 	}ARGEND
>
> Then you could run something like
>
> 	9pserve -c `namespace`/acme tcp!*!12345

this doesn't work - gives: malformed address.

seems like dial() doesn't accept socket path names.
I'll have a look if I can fix this ...


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] plan9port: tcp servers

[Russ Cox]

> seems like dial() doesn't accept socket path names.
> I'll have a look if I can fix this ...

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

Re: [9fans] plan9port: tcp servers

[Enrico Weigelt]

* Russ Cox <rsc@swtch.com> wrote:
> > seems like dial() doesn't accept socket path names.
> > I'll have a look if I can fix this ...
>
> sorry, that should be
>
> 	9pserve -c unix!`namespace`/acme tcp!*!12345

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 ?

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

That would be fine, why did you decied against ?


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] plan9port: tcp servers

[Russ Cox]

> 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 ?

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.

>> i had considered not requiring the unix! once,
>> but i decided against it.
>
> That would be fine, why did you decied against ?

network addresses and files are different kinds of names.
mixing them would introduce ambiguities, like what
if i have a file name 'tcp!bell-labs.com!http'.
also there was no obvious error response if you
dial "a!b!c!d!e".  is it a malformed address?
not if a file name a!b!c!d!e exists.  but in general, yes.

russ

Re: [9fans] plan9port: tcp servers

[erik quanstrom]

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

> network addresses and files are different kinds of names.
> mixing them would introduce ambiguities, like what
> if i have a file name 'tcp!bell-labs.com!http'.

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).

> also there was no obvious error response if you
> dial "a!b!c!d!e".  is it a malformed address?
> not if a file name a!b!c!d!e exists.  but in general, yes.

if dial strings are written with / and not !
	/net/tcp/bell-labs.com/http,
an appropriately constructed namespace could
allow the "correct" fileserver to pass judgement.

- erik

Re: [9fans] plan9port: tcp servers

[Eric Van Hensbergen]

On Sun, Jun 1, 2008 at 10:41 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>
> if dial strings are written with / and not !
>        /net/tcp/bell-labs.com/http,
> an appropriately constructed namespace could
> allow the "correct" fileserver to pass judgement.
>

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

          -eric

Re: [9fans] plan9port: tcp servers

[erik quanstrom]

>>
>> if dial strings are written with / and not !
>>        /net/tcp/bell-labs.com/http,
>> an appropriately constructed namespace could
>> allow the "correct" fileserver to pass judgement.
>>
>
> Why include the tcp path element?  Name resolution should be able to
> determine the best network path to the service.

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

Re: [9fans] plan9port: tcp servers

[Enrico Weigelt]

* Russ Cox <rsc@swtch.com> wrote:
> you can run
>
> 	verbose9pserve=2 vacfs ...
>
> and you will get a lot of debugging messages on standard error.

thx, I'll have a try.

> 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.

My feeling is not that random messages get dropped, but writes
or opening for write. So this problem would sit somewhere
within/below handle().

> >> i had considered not requiring the unix! once,
> >> but i decided against it.
> >
> > That would be fine, why did you decied against ?
>
> network addresses and files are different kinds of names.
> mixing them would introduce ambiguities, like what
> if i have a file name 'tcp!bell-labs.com!http'.
> also there was no obvious error response if you
> dial "a!b!c!d!e".  is it a malformed address?
> not if a file name a!b!c!d!e exists.  but in general, yes.

hmm, I've introduced an 9P URL scheme in my libmixp.
It's not fully specified and can't handle all socket types yet,
but at least for TCP streams it's - IMHO - quite convenient.

eg: 9p://host:port/

Maybe I'll someday use the (currently ignore) path component
for chroot.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------