FreeLists / openbeosnetteam / [openbeosnetteam] Re: Status update

[Ksyu & Dima <k2d2@xxxxxxxxxxxxxxx>]

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

>