Date: Fri, 25 Aug 2006 11:33:36 -0600 From: Brett Glass <brett@lariat.net> To: Archie Cobbs <archie@dellroad.org> Cc: Julian Elischer <julian@elischer.org>, net@freebsd.org Subject: Re: Big PPTP server Message-ID: <7.0.1.0.2.20060825110346.075161f0@lariat.net> In-Reply-To: <44EF2262.7020009@dellroad.org> References: <7.0.1.0.2.20060810201735.067258b0@lariat.net> <44DBF2BB.5080202@micom.mng.net> <7.0.1.0.2.20060810212047.073f0078@lariat.net> <44DBFC05.6080804@elischer.org> <7.0.1.0.2.20060810220804.08de8568@lariat.net> <44DCB4D8.4020901@elischer.org> <44DF51C1.8000306@dellroad.org> <7.0.1.0.2.20060813182130.06f54060@lariat.net> <7.0.1.0.2.20060825091302.074f8008@lariat.net> <44EF2262.7020009@dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:16 AM 8/25/2006, Archie Cobbs wrote: >The ng_pptpgre node handles the "data packet" level of PPTP, but most >of the complexity in PPTP is in the higher level protocol for setup >and teardown. You'd have to get that in there somehow. I suppose that the call control facility could be implemented in the kernel, but it's probably better to handle it in user space, since the call manager behaves like any other program that listens on a TCP socket. If call management is done in user space, it's necessary to keep tabs on all the calls in one of three ways. mpd and pppoed use one master process that tracks them all. The alternatives are to spawn separate processes to track each one, as PoPToP does (high overhead!), or to go threaded, with one thread per call (probably the most efficient way to go). If the daemon were to use one master process as mpd does, much of the code from mpd could be reused. The state machine could be lifted from mpd nearly verbatim. Brian Somers, are you monitoring this list? Are there any potential pitfalls I'm overlooking here? Would patches be needed in ppp(8)? --Brett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7.0.1.0.2.20060825110346.075161f0>