[openbeosnetteam] Random muslings
- From: Zenja Solaja <solaja@xxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 1 Nov 2001 16:35:53 +1100
Hi all. I've bowed my head in shame a few weeks ago, and what can I say,
BeOS is like a drug which (once addicted) is a habit hard to break. Elate
isn't as much fun as I thought it would be, and I'm slowly becoming aware
that there may be a possibility that I'll come crawling back to the lovin'
OpenBeOS arms (if you'll take me back :-)
What does the OpenBeOS networking team need to implement?
1) The Network Kit front end.
This is the API presented to the user. User applications use the interface
by referencing BeAPI header files and Posix header files. The network team
needs to re-implement the following frontend (from the BeBook):
a)- BNetAddress class (convert net addresses to generic internal
type) - easy
b)- BNetBuffer class (allocate buffer and append/delete data) - easy
c)- BNetDebug class (debug info) - piece of cake
d)- BNetEndpoint (object oriented socket - wrapper for socket calls)
- slightly moderate
e)- network sockets - moderate to time consuming (the meat of the
kit).
- socket()
- bind()
- getsockname()
- getpeername()
- recvfrom()
- sendto()
- send()
- recv()
- listen()
- accept()
- connect()
- closesocket()
- shutdown()
- setsockopt()
- select()
f)- BSD network database interface - easy
- gethostbyname()
- gethostbyaddr()
- getservbyname()
- herror()
- inet_addr()
- inet_ntoa()
- gethostname()
- getusername()
- getpassword()
g)- Network settings - easy
- findnetsettings()
- setnetsettings()
Thats all we need to be source compatible.
h) - additions to the API (wish list)
From the OSI layered model point of view, the front end could
corrolate to the Transport and Session layers.
2) The Network Kit back end
This is the actual net_server which interfaces with the kernel/hardware.
From the OSI perspective, it provides the functionality of the Data-Link and
Network layers. The average developer writing a network application
considers the back end to be a black box. Until I finish reading the
FreeBSD design book, I cannot comment on the structure of the black box.
Marcus Overhaggen from the Media Kit team did an excellent job of
demonstrating how to convert the B header files into a dummy C program with
pluggin functions - empty pluggin functions for now (a single debug printf()
to show status), but functions which will be filled in as the team
progresses. Marcus honestly believes that binary compatibility is possible,
and so far he can get 3rd party apps to link without errors (of course, they
dont run yet). I think that a couple of members of the Networking team (a
couple and no more) can attempt the same with the above front end. This
will show progress to the rest of the OpenBeOS teams, and will allow the
very first files to be checked into CVS. As far as everyone else is
concerned, the black box can be a rip off of the FreeBSD networking
implementation (hey, nothing to be ashamed of, its one of the best in the
industry), and all they really want is source level (100% possible) and even
better, binary compatibility (possible).
Anyway, I'm prepared to take the challenge of preparing the header/pluggin
files. Is that OK with you Jean (glorious team leader)?
Any thoughts, suggestions?
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
Other related posts:
