[openbeosnetteam] Re: Unix Sockets

Hi Sylvain,

> i think to implement unix sockets (AF_UNIX domain) in the following fashion
> :
>
> socket() : allocate a file descriptor
>
> bind() : associate the file descriptor with a file (with fopen())
>
> accept() : returns the file descriptor or dup()
>
> for unnamed socket, create a pipe with mkfifo
>
> For block/non_block options, set the corresponding options on the file.
>
> Do you think this should be allright ?

For the proposed behaviour behind each sockets calls, I agree: using anonymous
or named pipes is a way to do it. Another way is to use your own ring buffers
(Axel wrote a great ring buffers support for... pipefs and keyboard driver
IIRC), but let's start with the simplest way, pipes.

> Other questions :
> -where can i find the source of the ioctl() function in the source tree ? It
> seems to do all the work in the socket() function.

The libnet.so/libsocket.so communicates with the network stack thru the
/dev/net/stack pseudo-device published by net_stack_driver.
The source of this pseudo driver is located under
src/add-ons/kernel/drivers/network/stack/net_stack_driver.c

Give a look at this design graphic:
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/obos_net_stack_design_1.gif

But you SHOULD NOT change this gateway just for Unix sockets!
Nor should you tweak net_stack_driver.c:net_stack_control().
The net_stack_driver.c and the network core module are (or should, at least) be
as much as possible protocols agnostic.

What you need to do is writing a protocol module that handle the AF_UNIX/PF_UNIX
addresses/protocom domain. The current stack code only have AF_INET domain
implemented. I know, the inner details of our stack protocol modules are very
hard to get, mostly because that's a plain port of BSD protocols source code
turned into modular design. :-(

So, it won't be that easy to integrate even a very simple feature like UNIX
sockets into our stack current design.

Anyway, I guess the simple UDP module could be of good inspiration for you here:
src/add-ons/kernel/network/protocols/udp/udp.c
If you look at bottom, you'll see it's a regular (kernel) module, which besides
the classical std_opts() module load/unload callback publish udp_module_init()
and udp_module_stop() callbacks.

These two callbacks will be called by the stack's core at module load/unload
time to allow the protocol to (un)register itself:

You needs to mimic these steps to register UNIX/LOCAL protocol domain

static struct protosw unix_protocol = {
        "UNIX sockets module",
        NET_UNIX_MODULE_NAME,
        SOCK_DGRAM | SOCK_STREAM,
        NULL,
        0,
        PR_ATOMIC | PR_ADDR,
        NET_LAYER3,

        &unix_init,
        &unix_input,
        NULL,                  /* pr_output */
        &unix_userreq,
        NULL,                  /* pr_sysctl */
        &unix_ctlinput,
        NULL,                  /* pr_ctloutput */

        NULL,
        NULL
};


At init:
        core->add_domain(NULL, AF_UNIX);
        core->add_protocol(&unix_protocol, AF_UNIX);

At stop:
        core->remove_protocol(&unix_protocol);
        core->remove_domain(AF_UNIX);

Then, all the inner details seems to be in this protosw struct you should
pass to (un)register a protocol to the stack code.
I barely myself understand how it's supposed to works. For example, I'm not sure
one protosw could support both SOCK_DGRAM and SOCK_STREAM modes. Otherwise, two
structures should be registered from the same module, to support both datagram
and stream UNIX sockets.

Maybe we could both work this out?

- Philippe

Other related posts: