From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <ccfa273ec0ee54fb6c533db5660e9290@plan9.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9p srv-ing on a port
From: mirtchov@cpsc.ucalgary.ca
In-Reply-To: <cd9922c13e490c570678ed5a1f0bdde4@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Fri, 16 Jan 2004 17:40:03 -0700
Topicbox-Message-UUID: bb8b91a2-eacc-11e9-9e20-41e7f4b1d025

> What is the real question?

Skip's answer will probably suffice.

Originally I wanted to have a threaded server listen to a port on
which many clients can connect, similar to what fossil and kfs are
doing on 17008. Clients do:

	srv tcp!somesuch!someport blah /mnt/blah

and that's all...

Initially I thought it may be enough to build a Tree structure proper
and run srv() on it by setting (Srv *)s->infd and (Srv)s->outfd to be
the file descriptor obtained by accept(), but that doesn't seem to be
the case.

I admit I haven't dug through other servers' sources too deeply.

Something else I'm interested in doing is having a /srv (or a similar
fs alternative) on which remote machines can post file descriptors to
parts of their namespace.  A srvfs that will post on a remote machine
in other words.  Just to make sure that the trivial way doesn't work,
I tried:

	home% import -c octarine /srv /srv
	home% srvfs tmp /tmp
	exportfs: can't read initial string:
	home% mount /srv/tmp /n/sources
	mount: can't open /srv/tmp: device shut down
	home%

Anyway, there's no excuse for not digging in deeper, except perhaps
that it's Friday :)

andrey