[openbeosnetteam] Re: Where next?
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 18 Feb 2002 16:50:03 CET (+0100)
> 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
Hey David, you're great! :-)
> 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.
Having just looked at the source for pools.c, they is not much reason
for being slower than malloc() - and in the long run, I guess they also
can be faster.
But you could have a read/write lock for the pools, so that you only
have to block other threads when you really need to - or have a per
pool lock (could be a bit expensive, though; I don't know how cheap
semaphores are).
Currently, it acquires/releases the sem when it checks for free memory
in a pool, but it does an unlocked (mp = mp->next) which could be a bad
idea - that's a bug.
In the long run, it would also be nice to give pools back to the system
when there too many unneeded around.
> 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?
I fully agree with you, it really makes sense to do that now.
> 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).
hehe :)
I don't have too much time right now, because I have pretty much my
hands full with BFS and stuff.
But it's not needed to do a kernel driver right now: the communication
between the library (sockets) and the server (as long as it is in
userland) stays pretty much the same - if there is a /dev/socket
driver, the library would talk to it, and that one in turn would talk
to the server, both via ports, and the socket driver would merely
forward those packets unchecked to the server.
So it really doesn't matter that much if the library talks to the
driver or the server directly - we could add a driver at a later point
without having much work.
Adios...
Axel.
Other related posts:
