[openbeosnetteam] Where next?
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: "OpenBeOS Network Team" <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Mon, 18 Feb 2002 01:05:42 -0000
What follows is a progress report and what I think we do next.
- arp basically works and is about 90% complete.
- the basic structure is now in place for modules and interactions
- we can do ip but not yet defragment or reassemble
- icmp echo replies work well
- udp checksum is done, nothing else
- tests are in place for much of the basic stuff
The pools test will show they're much slower than using malloc/free, but
they do provide a more consistent set of results. In my ping reply testing I
saw results very consistent with the pools, but all over the place with
malloc/free which I guess is understandable given what else is going on with
the system, so they're still there.
I think we now need to try and finish outlining the project. Basically we're
up to a protocol layer (udp) and so the next logical step up is a socket
layer. This raises a lot of questions and brings up some of the "harder"
stuff, but I really think we should go for it now. Why?
1. Well it'll need doing and by doing it now we prove/disprove it can be
done.
2. We need to be able to test what we write, which is hard unless we can run
apps against it all. To run apps we need sockets.
3. It's the missing link in the picture. Once we have the socket layer then
we have a framework that allows people to start working on bits inside it
without wondering how it all fits together. It's much easier to work on a
small project within a larger one that be faced with the prospect of doing
the whole thing!
Now, Axel said he thought we should use a /dev/socket to create sockets.
Sounds like a good idea, but how do we implement it and how do we interact
with it? Maybe Axel can share his ideas a bit more? If I can understand
enough I'll have a crack at the device driver if we need one, but I've never
done one for beos before so it'll be better if someone else does it (I
suspect I won't be trampled in the rush of volunteers).
So, my roadmap from here looks like
- finish architecture
- develop socket layer for udp (control blocks etc)
- add routing
- write a simple userland test app for udp (client/server type thing?)
- add ioctl interface and get a simple arp app working
After that? Well there is a long list! Amongst it we find
- add fragment support to ip
- add tcp
- add remaining control structures to get tcp working with sockets
- full udp support
The list goes on and on!
Anyway, thoughts?
david
Other related posts:
