[openbeosnetteam] Re: moving ppp to other location
- From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
- To: "OpenBeOS Networking" <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Thu, 18 Sep 2003 18:18:15 +0200
> > That would be nice to have, yes. Although we probably don't need to
> > support any other DUNs for R1, do we?
>
> No, we don't.
> Beside, except SLIP, I don't even know other non-PPP DUNs...
Me, too.
> But it'll have the benefit to:
> - *resolve* our current "ppp interface manager" module naming *issue*:
> No more two "ppp" called subfolders under src/add-ons/kernel/network/*,
> but network/ppp/* for all PPP related stuffs and
> network/interfaces/dialup (or dun) for the Dial Up network interfaces
> manager module.
>
> - add a higher abstraction level between the stack interfaces manager
> and
> our soon PPP interfaces manager and any future
I think that any other probocol needs to be implemented as a competely new
interface.
SLIP is only intended for IP (Serial Line IP). This means that nearly all
PPP features are not needed at all.
I do not know where I could abstract the PPP interface to make writing SLIP
easier or more integrated.
I just had a look at the RFC and SLIP is no real protocol. There is no
authentication, no compression, no reliability and no dial-up sequence. You
just set up you SLIP link by selecting the serial line you want to use and
that's all. It does not even have an integrated feature to negotiate the
peer's IP address. Thus, the user does not have any control over SLIP except
saying which serial device to use and changing a flag that says if it is up
or down. CSLIP is more complicated becaues it compresses the IP packets, but
nothing more.
> - make Dial On Demand, Auto-Retry & Disconnect on Idle features
> available for any kind of
> dial up protocols, starting with PPP obviously
The problem is that the Send/Receive methods are very interface specific. I
could add an additional layer for this, but still, Up()/Down() would be
specific.
> But, maybe it's PPP that is more abstrack that "Dial Up Networking"
> concept...
> Waldemar?
I hope I have understood you correctly.
PPP is very integrated in itself and it can handle really everything you
need or want to do. Even Bluetooth uses PPP (through a virtual serial link).
There is no need for other dial-up interfaces. If they do not use the PPP
base protocol they should implement their own interface module.
PPP is also problematic to further abstract in that it has support for
multilink protocols. I did what I could to abstract the multilink support,
but it is not possible (from my point of view) to hide the multilink feature
without making the PPP stack extremely complicated so that each packet can
be filtered out and routed to other devices and the whole state machine can
be replaced or events can be filtered, too.
With my PPP implementation I aimed at making modules easy to implement. I
hope to make the amount of lines needed to create a new PPPDevice (be it
PPPoE, Bluetooth, or Modem) or PPPProtocol (IP, IPX, etc.) less than what
other implementations need and at the same time much more readable (soon we
will see if this is true ;). This is why I chose C++ over C (with the
drawback that it is a static library at the moment).
Waldemar
Other related posts: