Since sending this I asked Ron if I could quote him in
an email he sent to me, and received permission to do
this..
>On 05-Dec-02 Ron O'Hara wrote:
>
>
>>I should have also mentioned a bit more about the design goal of the
>>'modem pool' stuff.
>>The network design issue was to have a hub with a large number {M} of
>>remote ppp connected devices but have the links mapped to a smaller
>>number {N} of modems. This allows a maximum of {N} active links
>>concurrently, but acces to the larger {M} devices.
>>
>>The design was for a tech support center where at any given time there
>>is a maximum {N} technicians working but who support a set of {M} remote
>>sites... For simplicity the assumption that each tech will only be
>>actively working on one remote system at any given time. In reality,
>>they might have multiple sessions going and/or there may be multiple
>>guys working on a single remote device. Add to that the fact that not
>>everyone will have a remote session going and it all just becomes an
>>approximation to guess how many modems need to be provisioned ...
>>Since you can get nice cheap 8 port PCI serial cards and put two in each
>>chassis, this approach lets you hang 16 modems off each hub device.
>>Scaling up just means setting up more hub units and configuring the
>>routing in more interesting ways. There is not really any logical limit
>>to the number of remote units that can be mapped to the other end
>>(except for IP addressing limits), but as a 'guesstimate' we allowed a
>>10-to-1 ratio of remotes per hub port. Thats probably overkill, but the
>>intention was also to allow the remotes to 'call home' to log event
>>data. That is a similar scenario to running a PSTN based ISP service
>>(hence the 10-to-1 provisioning).
>>
>>The real deployment was meant to support 1500 remote sites.
>>
>>I still think pppd needs to be enhanced to support demand dial PLUS
>>inbound call answering on the same port.
>>I spent some time looking at this and trying to find a solution that
>>would allow pppd and mgetty to cooperate for this. It looks like the
>>demand dial pppd task needs to start mgetty as a sub task when it is
>>idle, then mgetty needs watch the modem to die if it gets a ppp
>>negotiation (AutoPPP) rather than start pppd as a subtask to itself. If
>>a demand dial situation arises for the parent pppd, the waiting mgetty
>>could be killed (freeing the modem) and the normal call out processing
>>could start.
>>
>>A fair bit of work to modify pppd and fork a version of mgetty.
>>
>>Ron
>>
>>
>>
>>
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 9:53 AM
Subject: [leaf-user] Modified ppp.lrp for Bering
> Hello,
> I have a modified ppp package available, and
> would like to know where to put it.
> This package was based on ppp-2.4.1 with the
> patches from the Bering 1.0 ppp package, as well as
> an additional patch which I got from Ron O'hara.
>
> This patch allows a ppp server pool to be configured.
> Presently, I'm running 8 modems dialing out to
> around 20 different clients with this setup. This
> package does not allow both incoming and outgoing
> connections to work as configured. It is outgoing
> only because it takes over the modem.
> The original patches had the supporting work
> using msql and perl, my stuff uses shell code
> to do things.. His stuff is nicer, but, my stuff
> should still fit on a floppy installation at the
> expense of possibly being harder to configure, since
> the information is stored in a flat text file that
> gets grepped on.
> I also had to modify the pppd to run execve on the
> device script like it does on the ip-up and ip-down
> scripts, because otherwise I was loosing my environment
> settings, which are needed.
>
> Bill Suetholz
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> ------------------------------------------------------------------------
> leaf-user mailing list: [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
>
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
