netdev
[Top] [All Lists]

Re: RFC: PPP over X

To: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Subject: Re: RFC: PPP over X
From: Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>
Date: Thu, 3 Feb 2000 15:15:01 -0500 (EST)
Cc: Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>, netdev@xxxxxxxxxxx, axboe@xxxxxxx, Mark Spencer <markster@xxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Marc Boucher <marc@xxxxxxx>, paulus@xxxxxxxxxxxxx, Ben LaHaise <bcrl@xxxxxxxxxx>
In-reply-to: <20000203111517.I72648@sfgoth.com>
References: <Pine.GSO.4.20.0002021030520.22723-100000@shell.cyberus.ca> <14489.34346.789910.342715@styx.uwaterloo.ca> <20000203111517.I72648@sfgoth.com>
Sender: owner-netdev@xxxxxxxxxxx
Mitchell Blank Jr writes:
 > > I think that for PPPoE at least sockets (of some form) are the way to
 > > go, because with a sockets approach we have code that maintains
 > > consistent semantics.
 > 
 > I agree, especially if you're running a PPPoE session server, where
 > you need hundreds of simultaneous sessions demuxed.
 > 

Serving up connections on such a scale brings up some issues.  Most
importantly, there should be a single process which negotiates all
incoming connections.  I deal with this in my most recent pppd patch
by forking after having established a new connection; the child
process then handles that connection and the parent continues to
listen for more connections.  This is an issue since a pppd daemon no
longer has exclusive access to data over a particular "device".  I
don't know how this applies to PPPoATM, but I think it would be good
to agree on what the correct behaviour should be in such situations,
regardless of the back-end device/protocol.


Michal Ostrowski
mostrows@xxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>