[openbeosnetteam] Re: Change of heart...
- From: <j-schwerer@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: 5 Feb 2002 14:59:18 MST
Hi all,
[David wrote...]
>Considering the nearer future basically means =
>that we look at creating a userland network stack that's compatible with=
=
>beos 5.
Agreed for sure.
As far as I can tell I believe this is what Michael is expecting from us
anyway, so we're not going into trouble by choosing this way :o)
However I am not technically good enough yet to fully understand where th=
e
difference lies between user-land and kernel-land... ^_^ All attempts to
explain that difference that I have read in the past were in vain as far =
a I'm
concerned :o)
What I'd like though is to have as much source code as possible that can =
be
"plugged as is" within both NewOS and BeOS.
>The change will also lower the entry requirements for everyone
That's good news :o)))
[Emmanuel wrote...]
>> This is what I think it is the better for the moment, getting experien=
ce
>and
>> continue to make the BeOS 5 keep "alive" with a network stack replacem=
ent:
[....] (snip)
>> PPPoE
Damn, I NEED this for Internet access with ADSL :o)
[that was Cain...]
> My two cents worth... I agree!
Well, if everyone here agrees with David, that's pretty good, heh? :o)
[...and David again...]
>Hmm, well let's try to be more objective and focused on what needs doing=
!
>
>This is a first hash at some milestones/ordering of what needs doing. N=
B
>this is a discussion item!
>
>1. basic infrastructure.
>By this I mean network buffers (mbuf/skbuf type implementation), interfa=
ce
>details to/from existing network drivers, how modules interact, etc etc
>This should get us to a point where we can actually get data from/send d=
ata
>via a nic, and have some sort of basic module loaded instead of the exis=
ting
>net_server (even though it won't do anything but test)
Agreed.
Getting data / sending data via a NIC was something Emmanuel was looking =
at a
while ago. Emmanuel, is it possible for you to commit to a date by which =
you
can send me your work? I'd really appreciate if we didn't have to start i=
t
over again ^_^
>2. link level layer
>So, now we can get packets we start actually trying to do something with=
>them. This involves determing the type of packet and what it contains, t=
hen
>routing accordingly.
>modules: ethernet,
Agreed.
>3. network layer
>We got a packet, but what is it? Again, look at packet and decide what t=
o do
>next. This includes routing.
>modules: ip, arp, icmp
>
>NB I'd also like to build in a dhcp client service so that we don't have=
to
>run a seperate application to fulfil dhcp client services. I think it
>belongs in this layer.
Agreed.
Mmmmhhh.... sure would be cool to have fully working DHCP support =3DP.
>4. transport layer
>How do we get the contents of the packet to where it's required?
>modules: tcp, udp
Agreed.
>5. application layer
>Move the data to/from the user.
>modules: sockets, libnet C++ wrapper
Agreed.
>Now, I've used ip as meaning ipv4 as the intent is to replicate what was=
>offered by the net_server. If we decide to expand on that, then great, =
but
>for R1 this is really what we're talking about (IMHO).
IPv6 is definitely *not* a priority and I doubt other protocols would be =
of
much use in the very close future. For sure we'll want to go IPv4 first. =
We
just keep in mind that if our architecture is modular enough, we'll be ab=
le to
plug ATM, MPLS and IPv6 right in at a later time =3DP
>I have some ideas about how this should work, which I'll try to outline
>here. Be aware I haven't actually got a total working blueprint in my h=
ead!
>
>- each network card driver is a module
>- each network component is a module (as far as practicable)
>
>o When we start, the system loads and adds the network drivers as requir=
d.
>o When the net stack starts it goes through all the devices and modules =
and
>allows every device driver the chance to init every module. This would m=
ean
>that the ethernet module would be offered to every device, even if it's =
a
>ppp link. During the init such things as addresses are setup and
>configuration takes place.
>o The entire net stack can be stopped. Once restarted the entire collect=
ion
>of modules, including the network drivers, should be reloaded and the en=
tire
>init process done again. Don't know if this is possible.
>o Every module should be as self contained as possible and will live in =
it's
>ownd irectory with all private headers and so on in that directory. Publ=
ic
>headers live somewhere else (not sure where??).
Agreed
>o No module can make assumptions about subsequent or previous modules.
Let's not forget though that at each level the recognition of the packet =
type
is done by the lower layer.
Tell me what you think about the following: each protocol could be implem=
ented
via a separate add-on / library / whatever, which would export a "rule" t=
hat
would enable the lower layer to know which protocol to give the data to..=
=2E.
Looks unclear... allow me to put it clearer with an example:
Let's say I receive some data through NIC #1. I am the link layer. I know=
above me I have modules from the network layer. Let's say on the computer=
modules IPv4 and IPv6 are installed.
Module IPv4 has a function that tells me the rule to recognize IPv4 is th=
at
the packet is variable length, which gives me the minimum and maximum len=
gth
and how to check from the header is the lenght is correct, and how the he=
ader
is organized so I can check if the header actually looks like IPv4 or not=
=2E
Module IPv6 has the same function, which tells me the packet (blah blah
blah)....
I am the link layer, so I have absolutely *no idea* how those modules wor=
k and
what they do, the only things I know are:
- I export an hook function (or I get messages) to accept a pointer to a =
data
struct that they give me to encapsulate for sending data, so upper layer =
can
call that function or send me the message. Let's say we have a hook funct=
ion
called
err_status BPleaseProcessThatData(datastruct &)
- I know all modules of the next layer have a "gimme_your_rule" function =
that
will give me info I can understand. Let's call that function
err_status BGimmeYourRule(rulestruct &)
- I export a pointer to the same data struct that I give them when I
decapsulated received data and I can call an hook function that belongs t=
o the
module I recognized thanks to the rules or I can send that module a messa=
ge.
Let's say we have a hook function called
err_status BHereIsYourData(datastruct &)
So when I start I call all the "gimme_your_rule" functions and keep a tab=
le of
those rules. When a packet arrives I apply the rules and whichever rule g=
ives
the best result determines which module I should tell "you've got a packe=
t"=1A
If that upper module is not loaded (I mean in case the service is not
activated, either from a user choice or because of some load time config =
that
might have said we don't need that service) or if it returns a BNotForMe
err_status I check if another rule might fit. If another rule might fit I=
try
again with the other module. If no rule might fit I generate an error.
>I'm sure there's loads more that I should add, but that should be enough=
to
>kick off a discussion.
>
>We should probably try to get together in IRC to discuss this more. I'm=
>around (UK time) Friday afternoon thru Tuesday morning.
Granted.
How would next sunday afternoon (European time, would be sunday morning U=
S
time) sound? We might want to set up a temporary channel on
irc.openprojects.net or some other server. What do you think? Will you be=
there?
Awaiting comments & reactions... :o)
Jean
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=3D1=
Other related posts:
