[openbeosnetteam] Re: general or PPP ideas

Hi,

>AFAIK, each used protocol (IP, IPX, etc.) must be specified and 
configured
>for each link (Ethernet, PPP). 

Configured? What do you mean?

> How is this done at the moment? 

There's no specification of which protocol should be used by a link or 
not.
Stack loads all protocols presents at startup, and each one, at init 
time, register itself 
against the stack as handling one or more specific protocol id/stack *
level* pair for a specific 
*domain*.

Example:
src/add-ons/kernel/network/protocols/ipv4/ipv4.c:ipv4_module_init():

add_domaine(NULL, AF_INET);
add_protocol(&my_proto, AF_INET);

my_proto point to a struct:

struct protosw my_proto = {
        "IPv4", // protocol name
        NET_IPV4_MODULE_NAME,  // module path/name
        0, // protocol type (SOCK_DGRAM, SOCK_STREAM, or 0 = n/a)
        NULL,  // domain list
        IPPROTO_IP, // protocol number 
        0,  // protocol flags
        NET_LAYER2,  // protocol layer level
        
        // follow protocol callbacks... 
};

The layer levels here are known as DoD (aka pre-OSI, or TCP/IP, layers) 
:

NET_LAYER4, Application Layer = OSI Application to Session Layers (raw)
NET_LAYER3, Service Provider Layer = OSI Transport Layer (udp, tcp) 
NET_LAYER2, Internet Layer =  OSI Network Layer (ipv4, icmp)
NET_LAYER1, Access Layer =  OSI Link and Physical Layers (ethernet, 
loopback, serial_ppp?) 

Current stack dynamicly build a protocols linked list.
Each protocol can to get whole domain's protocols for what layer he 
want; upper on reception, down(er?) on transmission.
 
> So, there is
>no possibility to add a protocol by just adding the driver. 

That how current stack protocols module (or driver, if you want) do it!

> It must be configured for each device. 

No.

> This means that we need a good configuration
>scheme.
>I think that it would be cool to use a structure to describe a 
connection
>(at least for PPP).

By connection, you mean the protocols stack for one opened endpoint?
Like BONE's bone.conf?

I'm like Axel here, I really don't like external configuration when it 
don't offer you value-added.
Protocols should discover each other themselves, by asking at runtime 
who is here, something like that.
On reception, the upper protocol to pass packet to may even be select 
by stack's core, not on each 
protocol own schema:

1) ethernet get a new packet, check his integrity, extract the 
demuplexing "id" 
(let's say 0x8000 (ipv4) here), remove ethernet specific from packet 
and handle it to stack "core", telling "hey, here a 0x8000 packet, and 
don't ask me what's a 0x8000 packet as I don't care" :-)
2) stack "core" find which protocol(s) knows about 0x8000 packet kind 
at this stack layer level (network, aka NET_LAYER2 in DoD model): ipv4, 
but a peeper/sniffer protocol could too!. 
3) He handle him (or them, if multiples) the packet 
4) ipv4 extract the demuplexing "id" (let's say 0x06 (tcp) here), 
remove specifics, and handle it back...
5) stack "core" find which protocol(s) etc etc...

On output, that's harder. TCP protocol require the sub-protocol being 
ipv4 or ipv6, and ip protocols can handle the packet to any link.
Currently, it's hardcoded: udp.c:upd_output() explicitly call the layer 
2 (Internet layer) IPPROTO_IP protocol handler. It's ipv4, obvioulsy. 
Same for our tcp protocol module.
And same for raw protocol module, which BTW only support IP!
 
>The structure describes which modules should be loaded and it defines
>substructures to configure each module. This is useful especially for 
our
>modular design (like I want to implement it for PPP).
>The syntax should be the same as for driver settings. The settings 
code
>could be reused and with our new OBOS implementation we can even save 
them
>to disk or modify them easily.

I don't agree about settings file when unnecessary, but 
Axel wrote already driver_settings API for OBOS:
src/kernel/core/driver_settings.c

>What do you think? At least, PPP should use this system. 

Dialup profiles are required for PPP link negociation, that's right.
But for PPP sub-protocols, it would be better if they can rely on some 
registering mechanism against the main PPP module (their caller).

>But, refering to the idea of using attributes for protocols/interfaces 
this
>is a possible implementation. IPCP would add the nameservers to the 
dynamic
>settings structure of the IP module, for example. This is similar to 
what we
>discussed.

Modifying a global settings file can't be enought, you'll have the 
stack to detect this modification.
By notification or by pooling (bad!).
However, if it's a dynamic, aka non-permanent setting, why storing it 
in permanent storage?
Why not just telling the new DHCP-obtained IP address of a link by 
calling the stack control main function (ioctl()!) ?

For DNS, as current implementation in our libnet.so is a BSD-like, I 
guess it's just a matter of adding/modifying to the /etc/resolv.conf. 
It's not much BeOS-ish, but maybe we could postpone for a better 
solution, no?

>If you do not want to use this scheme for the whole netstack may I use 
this,
>please? :))

If you want, start with this schema.
We always could make it better/clever afterward. If needed.

BTW, do you have already some proof-of-concept code to show us?

-Philippe

--
Fortune Cookie Says:

"Hey!  Who took the cork off my lunch??!"
                -- W. C. Fields

Other related posts: