Subj : 1/2 - LSPPPDlr 2003
To   : Mark Lewis
From : Michel Samson
Date : Wed Dec 15 2004 03:57 pm

Hi Mark,                                                             1/2

    About "LSPPPDlr 2003" in two parts of December 13:

MS> ...an image is worth a thousand words...
ML> What versions...  My thoughts have been to gather everything...
MS> ...relative to the programs or the archives themselves?...  I've
MS> gathered the addresses on which i intend to base my pages...
ML> Mainly just the archives...

    Oh!  Well, when i'm ready to zip it as a single archive and to call
it, euh...  `LSPPPDlr 2005', most likely, euh...  i'll add that one too!

                                 ;-)

MS> ...i was thinking my `LSPPPDlr 2003' UpDate is over-due for a switch
MS> to the 2004 edition so i began working on new dedicated pages...
ML> Cool...  I'll try to remember that...

    The time has come, it's still crude but i noticed how much damage i
had to repair after my ~ISP~ made some changes a few months ago...  I've
been busy clearing up a few issues before i touched `2K4UpDat' so i hope
this wasn't urgent, you only get plain-text addresses but it's readable.

MS> The external dialer now handles two types of Packet-Drivers...  I
MS> also wrote a Batch-File to simplify the installation...
ML> Excellent!

    I have sympathy for Matt when he seems to find my setup process too
complex but i must respect author rights.  I might pack the Genuine .ZIP
Archives with my "GlueWare";  though, the final size (read the BandWidth
due to this alternative concept) worries me:  it causes another issue...

ML> I have {COMMO} v7...  How bad does it get if it is not registered?
ML> ...info within the commo77 archive...  ...some basic guesswork...

    It's been some time since i read the distribution files which don't
display directly in `{COMMO}', i tried to read the YahooGroups mail-list
yesterday (to find a precise quote about the status of `{COMMO}') but it
isn't `Lynx' friendly, to say the least, and i sort of forgot about what
i was supposed to do once `W2K' was finished loading!  I might try later
and give you at least a name but it will have to wait until a next post.

 > Problem:  ...modems on a network...  Solution:  ...Int-14 calls...
MS> An affordable solution, these days, could be Dial BackUp routers if
MS> one is no AOL customer or he never sends FAX documents...
ML> ...i'm not sure what you mean about the AOL stuff...

    Most Dial BackUp routers handle the MoDem without external help, it
means the ~PPP~ protocol is internal and hence the script as well.  On a
few rare models, the MoDem is made available over EtherNet:  i found two
from 3Com (3C886 & 3C888) and one from ActionTec (GEU114000-01)...  From
what i read, manufacturers take pride in advertising "AOL Compatibility"
so i conclude routers like these have something the others don't...  ;^)

ML> ...one...  ...figured out how to use his AOL...  ...without using
ML> the AOL software...  ...a matter of determining the proper logon...

    I'm please to read there's more hope than i previously suspected, i
certainly would be satisfied with a script solution if i depended on AOL
for my INet access (but there's little control over the ~PPP~ process if
it's supported internally, unless the FirmWare can be re-writen)!  There
is another solution:  Tactical's `DialOut/IP' $oftWare could control the
MoDem remotely but can `DialOut/IP' be supported by personal Dial Backup
routers?  I doubt it, such simpler devices seem to be relatively cheaper
to produce or there would be more models equipped with a MoDem server...

    The cost of the TacticalSoftWare license might explain, at least in
part, why a MoDem attached to a Dial BackUp router is controlled locally
instead of thru ~RFC-2217~...  After all, the ~CPU~ is already available
and managing the ~PPP~ protocol only involves more FirmWare code.  Also,
INet access would be lost should the main PC hosting ~PPP~ support fail.

    I considered a purchase.  One model seemed to support ~PPP~ locally
and something told me it was possible to get partial remote control:  in
the form of a "HangUp" feature, activity was sufficient to "trigger" the
"HangOff"/"Dial" process.  Information was so scarce i "put it on hold",
nonetheless - not to mention that i've read FirmWare horror stories!  :(

MS> ...to me it was like most ~BIOS INT-14~ drivers crawl at 9K6 bps...
MS> Your reference to a MoDem pool reminds me of emerging alternatives
MS> which the average BBSers hardly ever heard of, euh...  ...~NCSI~...
ML> ...that is where i first encountered a workable solution...

    But you're not the average BBSer and i only got one phone line free
for the ~PPP~ connection with my ~ISP~.  :)  A NetWork MoDem would still
be nice though:  no more quests behind the PC to find the ~RS-232~ cable
in order to connect it to another PC (twentysome to play with);  no more
power-down/power-up sequences just to make sure no dammage occurs in the
process;  no more unplanned investigations due the manipulations, etc...

    I didn't use DialUp often, lately, but it's no permanent situation;
i intend to move to a new appartment and i don't know what it will be so
a Dial BackUp router made a lot of sense:  DialUp & ~DSL~ are supported.

MS> But maybe HardWare performance has more inlfuence than i suspected!
ML> On my internal 10mb LAN, i'm getting 9kcps...

    Yet it tells me how much potential there is on a 100 Mbps one!  ;-)

[The present message concludes next...]
--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)