From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 17:33:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F408D16A4E2 for ; Fri, 25 Aug 2006 17:33:50 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72DF843D6E for ; Fri, 25 Aug 2006 17:33:45 +0000 (GMT) (envelope-from brett@lariat.net) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id LAA05136; Fri, 25 Aug 2006 11:33:34 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060825110346.075161f0@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 11:33:36 -0600 To: Archie Cobbs From: Brett Glass 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Julian Elischer , net@freebsd.org Subject: Re: Big PPTP server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 17:33:51 -0000 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