OS/2 Shareware BBS: 35 Internet/35-Internet.zip/kcg.zip/KCG.TXT

Text File | 1999-06-20 | 12KB | 221 lines

KCG.CMD for OS/2:  "Keep-Connected" to Internet
Freeware  R.J.Holmgren  [e-mail]  6/20/99

The Keep-Connected Gimmick (KCG) is a flexible, diagnostic tool to
determine the maximum amount of inactive time that an ISP will allow, and
then to keep connected to the ISP with minimal load on both your CPU and
your Internet bandwidth.  KCG prevents dial-up ISPs from disconnecting
users peremptorily for "idleness".

DISCLAIMER!  Attempts to bypass idle time-outs MAY BE PROHIBITED BY YOUR
ISP, and may even cause the ISP to terminate your dial-up account.  You
are hereby warned.  THERE ARE NO WARRANTIES WHATSOEVER; YOU ASSUME ALL
RISKS.  Delete this program NOW if you are unwilling to bear, solely, ALL
consequences of its use, misuse, or abuse, whether witting or unwitting.

  Requirements:
  ------------
OS/2 Rexx must be installed.

For the FTP method:
  RXFTP.DLL v2.0 (103701 bytes, dated 9-23-97) or higher must be located
  in the LIBPATH (usually \TCPIP\DLL).  RXFTP.DLL is a standard component
  of OS/2; obtain version 2.0(+) from IBM at:
    ftp://ftp.software.ibm.com/ps/products/os2/rsu/rsuinstn.exe

For the PING method:
  PING.EXE and RXQUEUE.EXE (standard OS/2 components) must be in the PATH.

  Command [nine optional arguments]:
  -------
kcg hostname|IPaddress
      user_ID
        password
          minimum_interval_between_hits (in seconds)
            maximum_interval_between_hits (in seconds)
              increment_amount (increase laziness, in seconds)
                L|m (progressive "L"aziness, or "M"aximum interval only)
                  F|p (use "F"TP or "P"ING method)
                    A|d (run as "A"ttached, or "D"etached, process)
kcg ?|/?|-?|help  command summary

  e.g.
kcg 152.163.212.93 anonymous [e-mail] 120 660 60 L F A  [defaults]
kcg ftp.aol.com anonymous [e-mail]  [as above but slower]
kcg ftp.microsoft.com
kcg 207.46.133.140  [same as "ftp.microsoft.com" above but faster]
detach kcg.cmd idt.net . . . 510 . . . D [override defaults 1,5,&9; Detach KCG]
kcg 192.20.225.4 . [e-mail]  [override 1 ("ftp.research.att.com") & 3]

Use periods as placeholders (i.e. to default to hard-coded values,
  which are stored in USER SETTINGS).

  Description:
  -----------
Two basic "methods" of operation are offered.  If your ISP recognizes PING
as "user activity", then KCG can use PING to "Keep-Connected".  But some
cheapskate toughminded ISPs no longer honor PING.  To manage them, KCG
connects to any FTP and asks a stupid question (what operating system the
FTP uses).  KCG remains logged on to FTP until you kill (or lose) the
connection (or until you abort KCG.CMD [Ctrl-C]).  Upon detecting
DISconnection, KCG reports enough debugging information to fine-tune
future operation to a shorter or (probably) longer maximum interval, for
greater effectiveness with the least load.  KCG displays its final
diagnostic messages to the screen, writes these diagnostic messages to
file KCG.LOG (located in the same directory as KCG.CMD, unless you run KCG
from a different "Working directory"), then exits.  Turn logging off by
setting variable "logfile='N'" in USER SETTINGS.

Interestingly, the FTP method tends to permit a longer maximum interval
of inactivity than the PING method.  Typically, Hosts that recognize PING
allow about 20 minutes of idleness before disconnecting, whereas FTP
connections established with the *same* Host often time-out after 30-45
minutes.

Launch KCG before connecting, or during a connection.  If you launch KCG
before connecting, every 2 minutes it will check whether a connection has
been established.  Two high beeps indicate Connect, two low beeps signal
Disconnect (after having been Connected); if using the PING method, a high
beep followed by a low beep indicates that you are connected but the Host
is not replying to Ping, or that the specified Host is "unknown", i.e.
you're providing a bad IP address or Hostname.  If high+low beeps persist,
you probably need to alter your settings:  correct a bad IP address, or
switch to the FTP method, or set user variable "retries" to a higher value
than [default=] 20.

If a disconnect occurs while KCG is running, but KCG has not yet detected
it and you wish to immediately reconnect, terminate KCG manually and
restart KCG from scratch before redialing (see "Note", below).

There are many ways to optimize the interval between hits.  Simplest is to
reset the connection timer in DOIP (Dial Other Internet Providers, a.k.a.
"IBM Dial-Up for TCP/IP") before dialing (click "Configure==>Reset Total
Connect Time"), then remain completely inactive, to get a rough idea of
how soon you time-out.  Note however that this will indicate a time-out
period applicable only to the PING method (FTP connections often have a
much longer time-out).  A different, trial-and-error approach might raise
the maximum period of inactivity permitted by your ISP [5th argument] to a
moderate level, e.g. 1800 (30 minutes), and set KCG's 7th argument to
"M"aximum so that only this (e.g. 30 minute) interval is used (no
"L"aziness).  If that works, then you might just leave well enough alone;
if it doesn't work, you could reduce the inactivity period in 1 or 2
minute stages until your ISP no longer disconnects you.

However, the RECOMMENDED, meticulous technique is to hit the ISP (with
either the FTP or PING method) at gradually increasing intervals, until
you are disconnected because of "idleness".  Between hits, KCG
"SysSleeps".  For example, set KCG's 4th argument at a low value such as
600 (10 minutes), raise the 5th argument to a high value such as 7200 (2
hours), and increment in large steps, e.g. 300 (5 minutes) [6th argument],
using 'L'azy mode [7th argument].  If your ISP never disconnects you, then
you don't need KCG (you've got a good ISP!).  Otherwise, start fine-tuning
by narrowing the minimum and maximum intervals of KCG operation to the
range during which you were disconnected (bounded by the reported "last
successful interval between hits" prior to disconnection and the "final
[failed] interval between hits" -- the first worked, while the second
failed to prevent disconnection).  Also reduce the increment to 30 or 60
seconds.

If you are disconnected while operating at the constant, maximum interval,
then either it is set too high, or else extrinsic factors caused
disconnection (possibly a long delay in Host response [the reported
"duration of last contact"] which affected the Host's timing).  Try
reducing the maximum interval by 30 seconds or so.  Remember that the
ISP's timing is usually hair-trigger and invariable; if the timeout is 40
minutes, you'll be offline by 40:01, every time.

Once you determine the optimum interval [5th argument], you can set KCG's
7th argument to "M", to hit your ISP only at that Maximum interval of time
(instead of gradually increasing the interval until you reach your
Maximum).  Note that for any change of settings to take effect, you must
terminate KCG.CMD and re-launch it.

For small load and fast response using the FTP method, you may want to
poll the Host to which you are currently connected, *if* it offers FTP.
Otherwise, communication with ANY Host in your neighborhood will persuade
your own ISP that you're "active".  (It's possible that your ISP monitors
users of its own FTP facilities, and might find "peculiar" your pattern of
constant connection with near-zero activity; whereas it would be unlikely
to monitor your usage of a remote FTP, or to try to discipline a user who
logs in _from_ another ISP.  Also, a few FTPs will only talk with users
who log in from a Host|IP with a valid DNS.)

Load also decreases if the server doesn't need to resolve the Hostname
that you provide (e.g. "idt.net") into an IP address (169.132.8.10).
So use the IP address directly; get it with DIG:
  http://kryten.eng.monash.edu.au/gspamt.html
Execute "Do DIG hostname->ipaddress".  Supply an alphanumeric Hostname,
and then use a numeric IP address listed in DIG's ";; ANSWERS:" stanza.
If you're using an *invalid* Hostname or IP address, or the FTP declines
to talk to you (bad userID|password?), then KCG will abort.  Find a Host
with rapid response, just one or two seconds.

Finally, you can run KCG as a Detached process, by using OS/2's DETACH
command and setting KCG's 9th argument to "D" (see command example,
above).  There will be no output apart from Connection|Disconnection
Beeps, the maximum interval ONLY will be used, no KCG.LOG is written to
disk, and you'll need a process killer to abort operation (such as
Ctrl+LMB in WarpCenter's "Switch to another application", with
SET KILLFEATUREENABLED=ON in CONFIG.SYS; KCG will be listed as "CMD.EXE" --
be careful, other processes may also be listed as "CMD.EXE").  But the
load on your machine will be reduced to the bare minimum.

General Procedure for Determining Maximum Wait Interval:
------- --------- --- ----------- ------- ---- --------
Do this one-time operation in two phases, with NO other Internet
communication.  Typically it takes 2-4 hours.

Suppose you know that the ISP won't disconnect you for at least 10
minutes.  Initially, command:
  kcg ftp.myisp.com anonymous [e-mail] 600 7200 300 L<cr>
Thus:
    minimum wait interval [arg 4]=10 minutes
    maximum wait interval [arg 5]=120 minutes (arbitrary; set it high!)
    "L"azy incremental step [arg 6]=5 minutes
On the first round, KCG hits the ISP in 10 minutes, on the second round
after 15 minutes elapse, third round after 20 minutes, etc.  Suppose you
are disconnected between intervals of 30 and 35 minute (1800-2100 second)
duration:  now command:
  kcg ftp.myisp.com anonymous [e-mail] 1800 2100 60 L<cr>
In other words, narrow the spread between minimum and maximum wait
intervals to 30 and 35 minutes, respectively, and reduce the incremental
step to 1 minute.  Suppose that in this second phase you are disconnected
when the current interval is 33 minutes:  you learn thereby that the ISP
times out and disconnects between 32 and 33 minutes of inactivity.  So now
you can formulate your final command:
  kcg ftp.myisp.com anonymous [e-mail] . 1920 . M [F|P] [D]<cr>
I.e. hit the ISP at constant 32 minute intervals.

Perform this procedure with both PING and FTP, to determine which method
tolerates the longest period of idleness.

Tip:  Instead of issuing runtime arguments, adjust the USER SETTINGS
(defaults), and then run KCG.CMD hands-off (without args).
Alternatively (easiest), establish a Program object on the Desktop, enter
"[d:\path\]KCG.CMD" in "Required path and file name", and enter the
arguments in "Optional Parameters".  To launch KCG as a Detached
process from a Program object, enter "DTACHKCG.CMD" (part of KCG.ZIP) as
the "file name" (instead of "KCG.CMD"); be sure to set "D" as the 9th
argument.  All *.CMD files should be situated in the OS/2 PATH!

Note:  RXFTP.DLL has some quirks.  When a connection is broken, RXFTP.DLL
freezes on all commands issued to the remote Host EXCEPT FtpPing.  This
has two implications for the FTP method (only):

1) To prevent freezing, KCG sends a one-byte FtpPing to verify that
there is a phone link to an ISP before commencing an "active" FTP
communication with the ISP.  Note carefully:  if you're using the FTP
method to keep-connected, then a successful send is what counts; it
doesn't matter whether the ISP replies to FtpPing or not, because there
will be a followup query concerning the ISP's OpSys to which KCG expects a
valid response.  BUT if you are using the PING method, then KCG requires a
reply to Ping.  The reason is that ISP's deem "activity" to be on *their*
part, not the client's part.  If they don't respond, then there's no
activity (or so I deduce, from observation of ISP behavior).

2) If a disconnect occurs, KCG needs to be terminated and restarted before
you can use KCG again (after reconnecting), because RXFTP.DLL needs to
completely reinitialize its relationship with the remote server (it
doesn't seem to be enough to simply LogOff; you have to quit the CMD.EXE
session that launched RXFTP.DLL and start again).