[openbeosnetteam] Re: Status update
- From: Ksyu & Dima <k2d2@xxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 17 Oct 2001 17:15:51 -0300
Hi everybody,
I am being a bit late with this reply but it is better later than never
(or so they say...)
>
>2/ On the *OpenBeOS Network Team* side:
>During the GeekDay event I could meet Guillaume Maillard, developer of the
>Eden application and
>Leader of the BlueOS project. Interestingly enough, they have someone from
>Gobe, Inc working
>closely with them. I also talked with Guillaume about a development that could
>possibly be part
>of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite, mapped
>after
>traditional BSD sockets. I *have started* this API rewrite.
>
Do you need a hand with the rewrite?
>Well hum... you can start thinking about the wish list anyway :o) It's quite
>easy, just tell ALL
>things you would like to see in OBOS Network layer. Don't mind if it is
>feasable at all or not, just
>think of a "perfect world".
>For example as far as I am concerned I'd like to see:
>Protocol-wise:
>- IPv6 support
>- ATM and PPPoA support
>- Full PPPoE and PPTP support of course, with CHAP authentication ^_^
>- Token Ring support (yes, I like Token Ring and think it is a well-designed
>protocol, and
>remember: I talked of a perfect world :P)
>
Here goes my wishlist:
- IPSec support
- IPSec key management: IKE and possibly photuris (btw, do we have any
plans on BSD-compatible sockets API? That would make the task of porting
of a lot of applications much easier)
- RSVP support (a perfect world clause applies ;-))
>
>Design-wise:
>- I wish every protocol would be handled by a separate add-on, then the
>necessary add-on gets
>loaded when a given kind of network traffic is recognized by the lower layer.
>
There are some security issues associated with this approach. One way
around could be for a user to select what protocol(s) he/she wants to use...
> That way it is
>easy to add protocols and to update some protocols' support. The add-on
>doesn't get unloaded
>from memory unless there is a given timer without network traffic observed (if
>the timer is
>reached however it will be wise to assume the machine has been disconnected
>from the network
>and warn the user about it :P)
>
Good idea... (some protocols support keepalives though (tcp comes first
to my mind) and can keep the connection open forever without any actual
data being exchanged)
>
>
>Feature/API-wise:
>- An automatic flooding and malformed packets protection for applications
>asking for it. e.g. an
>application may call a FilterArrivingPackets() function that would tell the
>network API to monitor
>certain kind of parameters, some kind of built-in firewall working at a lower
>level than user-
>launched firewalls.
>
I think flooding protection can be implemented the same way as OpenBSD
guys did it: when the queue of the opened (but not accepted) connections
becomes too big, connections are being randomly dropped from the queue.
The protection from the malformed packets is a bit trickier though: a
user may or may not want to use IP options, for example; on the other
hand malformed fragmented packets should always be dropped.
>
>- An automatic non-transparent firewall/proxy support. e.g. an application
>opens a connection
>(BNetEndpoint, BNetAddress...) and instead of having to care about
>firewall/proxy itself it tells
>the BNetEndpoint->UseProxyFirewall("socks5"). Then it doesn't care afterwards
>whether it's
>talking to a firewall/proxy or not, it justs sends the packets as it would to
>a given server, and
>the net_server handles the "translation" in firewall/proxy protocol for it.
>What's the benefit?
>Any application can then handle any kind of non-transparent firewall/proxy
>supported by the
>net_server without having to implement it. Kind of a "translator" function
>applied to the network
>if you prefer :o)
>
again, sounds like a good idea...
>
>- I read on OSNews (in Eugenia's interview of some *BSD people) about the
>project of BSD
>developers to enable sockets to be passed from a server to another one, which
>would enable
>QoS by ensuring a connection isn't dropped when a server is taken offline for
>maintenance of
>after a crash. I definitely want this in OBOS :o)
>
>Application-wise:
>- I'd like OpenSSL/OpenSSH and Apache to compile right out of the box
>(currently not the case,
>it's even lacking proper header files)
>
A must have, IMHO ;-)
>
>- I'd like to have a Perl build for OBOS with socket support
>
would be nice to have.
>
>I realize I've been quite long and already offered an insight about the
>wish-list topic :o) Well
>anyway... hope you made it until here and read a little bit of everything, but
>most of all... I hope you'll react to it ^_^
>
>Cheers,
>
>Jean
>
>
Cheers,
Dmitri
>
Other related posts:
