[openbeosnetteam] Design draft
- From: "Emmanuel Jacobs" <emmanuel.jacobs@xxxxxxxxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Mon, 10 Sep 2001 15:56:47 +0200
----- Original Message -----
From: "Zenja Solaja" <solaja@xxxxxxxxxx>
Subject: Is there anybody out there?
> Hi all. This list has gotten way to silent during the last week - is
> everyone on holidays or gone fishing? Listen, if anyone has second
thoughts
> or doubts about their ability to contribute to the OpenBeOS networking
> project (either lack of time or lack of motivation), just let us know (it
> makes planning easier if we're fully aware of who's commited). I've been
> notified by Nathan Whitehorn who also wanted to attempt a netserver
rewrite,
> and after hearing about OpenBeOS is interested in joining the project.
>
> Also, any comments in regards to the use-case diagram I sent out. We
> seriously need to start designing. I need to hear if people are still
> interested in the project.
>
Sorry, I had paintings to do in my house recently so... ok nevermind ;-)
1) I set up a freelists mailing list for the network team.
The list is named "openbeosNetTeam" and you can join it by sending a mail at
openbeosnetteam-request@xxxxxxxxxxxxx with with 'subscribe' in
the Subject field OR by logging into the Web interface at www.freelists.org.
I think it will ease mail exchange and discussions.
2) I re-installed BeOS 5.0.3 and it took me 2 days to stabilize the
installation because I had random resets... Some problems with drivers on
the
installation boot disk...
3) I installed a GCC distribution on my W2K machine and compilled GCC to be
usable as a cross compiler targetted to elf for x86. I successfully
recompiled one of the latest build of NewOS on that station (Cygwin).
4) I started thinking about the diagram/points you sent and here are some
preliminary comments:
Do we all agree that at first we will try to replace existing network
components of the BeOS with some we will build ?
As far as I know it is the case and I agree with that. I agree to start
coding on the Net_Server at first but is there any other smaller network
component we could try to implement at first as proof of concept ?
If we choose to work on replacement components, choosing first a component
which could be quite quickly developped and which could be quickly released
to the public as a working substitue for a real component of BeOS could be
great no ? I think, for instance, of the dhcp_client which clearly needs
rewrite ;-) But I don't have any idea of the way this component interracts
with the system (kernel/drivers/net_server) and if it is a good idea
or if it is even feasible to proof that component first, just tell me ;-)
Back to the Net_Server black-box:
Derived from the mail of Zenja, I propose the following structure for the
design document. I inserted my ideas in the text.
..........................
a) Interface with user processes:
- Exchange of conrol and data messages between user process and
net_server.
* CONNECTION_REQUEST/TRANSMIT/RECEIVE/DISCONNECT (+ other control
messages)
[
I can't add lot of stuff here because I don't have a lot of experience
with BeOS programming.
Are we sure we communicate with the NetServer using messages only ?
Is it possible at this time to list what are the messages types used in the
network context ? For instance we could implement a layer between the kernel
and
the net_server in order to trace out what are those messages ?
]
b) Interface with kernel / drivers / other system modules:
- Exchange of control and data between the net_server and the drivers.
* READ / WRITE (+ other control signals)
[
Same as above,I can't add lot of stuff here because I don't have a lot of
experience
with BeOS programming.
It seems we have enough documentation on how to write a device driver so
we should have a quite descent description of the interface between the
driver and the kernel. I'm I right here ? Do the drivers interface with
the kernel only ? Do the Net_Server have direct interface with the drivers
or not ?
]
c) Net_Server tasks:
- Maintain/manage sockets and network endpoints states.
- Manage the flows (from/to user process and drivers)
* Maintain/manage internal buffers + user process buffers (BNetBuffer
API).
* Manage Multiplexing (Quality of service, Fair protocol and flows
distribution, Load Sharing, Prioritization,...) and Demultiplexing
(based on IP:PROTO:PORT)
- Protocols Management.
* Encapsulation, decapsulation, CRC checking, size checking, ...
* Addresses management (ARP table, available TCP/UDP ports for
demultiplexing,
...)
* Routes management: routing tables and routing protocols.
- Provide API for addresses management (BNetAddress)
[
I think protocols (IP, TCP, PPP, PPPoE, etc.) should be implemented as
dynamicaly
loadable external modules. If we decide to go this wah, then we need to
design the module scheme. Such a desing can bring modularity (doh! ;-) but
could cause a lack of efficiency. This concept is inherited from my previous
work in the AllianceOS project. I still have design/concept papers about
loadable modules. But maybe is the BeOS architecture already such ?
I don't know where the BNetDebug thing could be located, any idea ?
I think all the above points are the same than those proposed by Zenja but
structurated in a different way.
]
d) Minimal requirements: Here are listed the first things the network team
will implement, there are still lots of things that are short-term
important
like IPv6, more drivers, etc.
- Serve an aribitrary number of processes (and so of sockets/endpoints)
- Must be able to connect several network types:
* drivers: MODEMs, ethernet LAN adapters.
* transport protocols: PPP & PPPoE (for modems and cable modems)/ eth
802.3 and v.2 .
* network layer protocols: IPv4, ICMP, ARP, DHCP/BOOTP, TCP, UDP.
- Must provide the tools/commands to check/troubleshoot those.
- Must work with actual BeOS archictecture
(binary compatibility at user process level)
.........................
Ok here are my 0.02$
Please roll the ball, send your comments ;-)
Regards,
Emmanuel
Other related posts:
- » [openbeosnetteam] Design draft
