[9fans] accept in dial(2)

[9fans] accept in dial(2)

[geoff]

There seems to be some confusion about which file descriptor
accept should take as its first argument: the one announce
returned, the one listen returned, or it doesn't matter.
A quick kernel grep suggests that only port/devsdp.c still
recognises the word "accept", per the comment

	write(ctl, buf, n); /* ignore return value, network might not need accepts */

at /sys/src/libc/9sys/announce.c:148.  dial(2) says
``Accept accepts a call received by listen'', which
isn't completely clear, but the example given uses
the fd returned by listen, which makes sense to me.
On the other hand, listen, listen1 and tftpd use the
fd returned by announce.

Does anybody know which fd accept should take, and if it
matters?

Re: [9fans] accept in dial(2)

[andrey mirtchovski]

> There seems to be some confusion about which file descriptor
> accept should take as its first argument: the one announce
> returned, the one listen returned, or it doesn't matter.
> A quick kernel grep suggests that only port/devsdp.c still
> recognises the word "accept", per the comment
>
> 	write(ctl, buf, n); /* ignore return value, network might not need accepts */
>
> at /sys/src/libc/9sys/announce.c:148.  dial(2) says
> ``Accept accepts a call received by listen'', which
> isn't completely clear, but the example given uses
> the fd returned by listen, which makes sense to me.
> On the other hand, listen, listen1 and tftpd use the
> fd returned by announce.
>
> Does anybody know which fd accept should take, and if it
> matters?


the listen one, i believe.

 here's a snippet from a service not unlike any other fs in p9:

		acfd = announce("tcp!*!18000", adir);
		if(acfd < 0)
			sysfatal("announce: %r");

		for(;;){
			lcfd = listen(adir, ldir);
			if(lcfd < 0)
				sysfatal("listen: %r");

			switch(rfork(RFPROC | RFMEM | RFNOWAIT)){
			case -1:
				fprint(2, "fork listen: %r");
				continue;
			default:
				continue;
			case 0:
				break;
			}
			dfd = accept(lcfd, ldir);
			if(dfd < 0)
				sysfatal("accept: %r");

			s = emalloc9p(sizeof *s);
			*s = fs;
			s->infd = s->outfd = dfd;
			srv(s);
			free(s);
			_exits(nil);
		}

andrey

Re: [9fans] accept in dial(2)

[rog]

> the listen one, i believe.

it's interesting that neither the "accept" nor "reject" messages used
by accept(2) and reject(2) are documented in ip(3).  i guess this is
because IP doesn't use accept/reject, hence things have got a bit
mucky, because it'll work whichever one you use!

from the way the messages are used (in /sys/src/libc/9sys/announce.c)
it looks as if the correct fd to use is that returned from announce
(which wouldn't have been my guess!), as the message contains the name
of the connection number to accept or reject, which wouldn't be
necessary were the newly opened control file used for the message
(this would know its connection number implicitly, so the extra argument
would be redundant).

i imagine there should be a place for the protocol required of /net to
be documented, so that if someone comes to implement a new protocol,
they know what is necessary. at the moment ip(3) is as good as it gets.

certainly dial(2) should probably be more explicit, and it looks like
the example there might be wrong.

i'm sure others know better than this!

Re: [9fans] accept in dial(2)

[rog]

> A quick kernel grep suggests that only /sys/src/9/port/devsdp.c still
> recognises the word "accept"

and this seems incompatible in another way with accept(2);
it looks like the "accept" control message expects a whole
pathname (which is then passed to namec()), whereas
accept(2) just passes the number of the newly open connection.

i guess SDP isn't much used...

Re: [9fans] accept in dial(2)

[Russ Cox]

[I forwarded geoff's original post to Dave Presotto,
who is not reading 9fans as vigorously as usual.
I'm posting this because his gmail account is not
authorized to send to 9fans.]

From: David Presotto
To: 9fans@cse.psu.edu
Date: Tue, 17 Aug 2004 13:06:18 -0700
Subject: Fwd: [9fans] accept in dial(2)

I'm indeed only reading 9fans sporadically.

The fd used should indeed be the one returned
by listen.  aux/listen et al are wrong.  However,
since we shut off datakit, it really hasn't mattered
because we currently don't have the ability to reject
IP calls.  Should someone change that, listen et al
should be changed to use nctl.

On Mon, 16 Aug 2004 20:30:48 -0700, geoff@collyer.net <geoff@collyer.net> wrote:
> There seems to be some confusion about which file descriptor
> accept should take as its first argument: the one announce
> returned, the one listen returned, or it doesn't matter.
> A quick kernel grep suggests that only port/devsdp.c still
> recognises the word "accept", per the comment
>
>         write(ctl, buf, n); /* ignore return value, network might not need accepts */
>
> at /sys/src/libc/9sys/announce.c:148.  dial(2) says
> ``Accept accepts a call received by listen'', which
> isn't completely clear, but the example given uses
> the fd returned by listen, which makes sense to me.
> On the other hand, listen, listen1 and tftpd use the
> fd returned by announce.
>
> Does anybody know which fd accept should take, and if it
> matters?
>

Re: [9fans] accept in dial(2)

[rog]

> The fd used should indeed be the one returned
> by listen.  aux/listen et al are wrong.  However,
> since we shut off datakit, it really hasn't mattered
> because we currently don't have the ability to reject
> IP calls.

just thought i'd mention that i just had a look at the devdk.c in the
3rd edition code, and it really does look like it *was* the fd
returned by announce which was used when accepting or rejecting a
call, at least, it was back then.

for instance dkanswer() is called (in dklisten()) before a line directory
for the new connection has been allocated. moreover dkanswer()
treats the data file corresponding to the ctl file it has been passed
as distinct from the data file corresponding to the line directory
as passed as an argument to the "accept" message.

i guess it might be desirable to change this behaviour,
but by the lights of that datakit driver, listen(1), (which
was contemporaneous with, and presumably worked with, datakit)
is correct, and the example in dial(2) is wrong.

if the behaviour was to be changed, i'd suggest that perhaps
the "line directory" argument to the "accept" and "reject" messages
be omitted, as it's redundant when used in this way.

just my 2c. as presotto points out it's not currently relevant.

Re: [9fans] accept in dial(2)

[boyd, rounin]

ahh, 8th Ed did this right.

these TCP/IP auto accept semantics are just stupid.
sure, i don't have much to go on (unlike datakit) but
it lets me raise the bar much earlier on if i so wish.

that BSD listen(2) fiasco is a joke.

this remings me of EGREG.  it'd be nice to hack
ape so various stupid calls returned ESYSV or
EBSD regardless of the supplied arguments.