[openbeosnetteam] Re: Testing the stack
- From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 01 Jan 2004 19:28:02 GMT
Hi again,
> > Do I still need net_server_driver? If I dont copy the net_stack
> > and
> > net_server driver files to
> > /boot/home/config/addons/kernel/drivers/bin, the commands do not
> > work.
>
> net_server_driver is only needed if you want to test the userland
> stack.
> The net_stack_driver is used to communicate with the netstack.
> Without it libnet.so will not be able to create a socket, etc.
Installing net_server_driver too should not harm, thought.
Our libnet.so use by default /dev/net/stack as his stack *gateway*, but
if a NET_STACK_DRIVER_PATH environment variable is set, this path will
be used instead.
It's how we switch from standard kernel hosted stack to userland hosted
stack.
> > >The userland test stack did not work very well (at least for me).
> >
> > I'm not using BONE, just straight R5.03 net_server... Should I kill
> > net_server before testing? I'm thinking so...
It's better, yes.
Or just disable one interface in Preferences > Network window, most of
the time it's enough to free it - aka not being own/open()'ed by R5
net_server stack).
> > Also, is our stack entirely contained within the libnet.so and
> > libnetapi.so files? I guess this harkens back to question about
> > whether either of the net_*_driver files are actually needed...
>
> Our libnet.so only talks to net_stack_driver. When you create a
> socket it opens /dev/net/stack and uses some ioctl() calls to configure
everything. The handle that is returned is the opened file handle to
the /dev/net/stack driver. This allows you to use POSIX read/write/
close like in a normal BSD environment.
Looks at this stack design overview picture:
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/
overview.html
The libnetapi.so is just a thin library wrapping C sockets API exported
by libnet.so into C++ classes.
The libnet.so contains two sides:
- Sockets BSD API, which in turn, thru the /dev/net/stack driver, are
really handled by the stack itself.
- Network naming services, gethostbyaddr(), gethostbyname(), etc, which
is the ISC BIND client implementation, ported.
This part live fully in userland, and requires access to /etc/
protocols, /etc/services, /etc/resolv.conf and /etc/hosts file to works
as expected, like under any UNIX system...
All these files are missing from our repository, and you need today
to create/copi them manually.
> > I want to iron out a very definite testing procedure that I can
> > thoroughly document.
> This would be really helpful for newcomers. Thanks.
That will be of great help. Send me whatever you'll came with, I'll add
to our documentation, both under CVS/current/docs/develop/net and
online, on my site.
- Philippe
--
Fortune Cookie Says:
One, with God, is always a majority, but many a martyr has been burned
at the stake while the votes were being counted.
-- Thomas B. Reed
- References:
- [openbeosnetteam] Re: Testing the stack
- From: Waldemar Kornewald
Other related posts:
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- » [openbeosnetteam] Re: Testing the stack
- [openbeosnetteam] Re: Testing the stack
- From: Waldemar Kornewald