iksd.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

These or other controls can be added if there is sufficient reason or demand.

6.5. Known Bugs

 . When commands are logged in syslog, the EXIT command appears twice.

 . wtmp entries show pids in hex due to length restrictions, so you'll
   need to convert them to decimal before using them with ps, kill, etc.

7. MONITORING

Unless you disable it, all IKSDs keep current session information in a shared
database.  The IKSD instances can be within one computer or running on any
number of different computers that share the same file system on the same
network.  The database can be monitored by the sysadmin with a simple
"systat"-like display program, which shows who is logged in, from where, and
what they're doing.  (The idea is easily adapted to other servers, such as
FTP.)  For maximum portability and reliability, the database is an ordinary
file on disk.

The IKSD database file should reside in its own directory (to avoid conflicts
with other servers that might use the same filename conventions), and this
directory and its files should be visible to the sysadmin without privileges
(e.g. by group access) but hidden from the public for privacy reasons if other
such logs (e.g. the ftpd log, syslog, etc) also are.

The database is a random-access file indexed by "slot number", which is
self-assigned during a quick search at startup.  Once a slot is claimed, there
is no more searching; each IKSD updates its own slot in place and does not
touch the others.  Slots never move.

When an IKSD instance starts, it must obtain a "slot allocation lock" before
it can claim its slot.  Otherwise there could be a race condition when another
IKSD instance starts at the same time, in which the two could wind up with the
same slot.

Since exclusive access is a nonportable concept, we obtain the lock in a
crude but portable manner, without recourse to kernel locks, interprocess
communication, semaphores, memory-mapped files, or other platform-specific
mechanisms:

 a. Create a temp file in the database directory called <ip>.<pid>, where
    <ip> is the local IP address as 8 hex digits and <pid> is my own
    process ID (PID) in hex (no leading zeros).  This is guaranteed to be
    a unique name (and if by chance a file of this name already exists, it
    can't possibly be valid, so it it's ok to overwrite it).

 b. Write my own ID string into the file.  The ID string is <ip>:<pid>,
    where <ip> is (again) my IP address as 8 hex digits, and <pid> is my
    PID in decimal (not hex).  (The reason for decimal here is
    readability, so sysadmins can easily enter it into other tools or
    commands; it has to be hex in the temp filename for compactness in
    case of 14-character filename limitations.)

 c. Try to open iksd.lck, which is the real lockfile.  If this succeeds,
    read its contents (an <ip>:<pid> string).  If the <ip> not the same as
    mine, consider the file locked.  If it is the same, extract the PID
    and check its validity.  If it is not valid, delete the lockfile.
    (Currently this step is skipped by K95 since it can't check PIDs.)

 d. At this point the iksd.lck file might or might not exist.  Try to
    rename the temp file to iksd.lck.  This will fail if the lockfile
    exists, in which case we sleep, loop, and try again, up to a certain
    number of times -- say 16 tries spaced 1 second apart.  If we fail to
    get a lock, we let the user on anyway, in the spirit of service over
    management.  If the rename succeeds, on the other hand, we have a lock.

When and if we have obtained a lock, we open the database file itself and
search the whole database (sequentially) for:

 a. Free slots (In-Use flag is 0), or:

 b. Stale slots(*), or:

 c. Any slot with our own IP and PID (a special kind of stale slot).

(*) In-Use flag is 1 and IP address is ours, but PID is invalid.

In C-Kermit only (not K-95) we also perform some housekeeping duties while
searching (the Windows APIs include no provisions for this):

 a. Whenever a stale slot is found, we free it (set its In-Use flag to 0).

 b. We remove all free slots after the last in-use slot by truncating the
    database file (this keeps the database file from constantly growing as 
    new highwater marks are reached).

Then we claim the first one of these that was found.  If no slot was claimed,
we add a new slot at the end and claim it.  If the database file did not
exist, we create it and claim the first slot.  (In Windows, the IKSD listener
simply deletes the existing database, if any, on initial startup.)

To claim a slot:

 a. We set the In-Use flag to 1, fill in the Server PID and IP address
    fields with our own PID and IP address, fill in the session-start and
    update time fields, and clear the other fields.

 b. Then we release the lock.

From this point, we can write freely into our slot regardless of locks.

Notes:

 a. Since all IKSDs follow the same procedure, only one can have a lock a
    at a time.

 b. The lockfile is readable text; it can be typed (cat'd).  The contents
    are the same format on every platform, regardless of byte order or
    word size.

 c. This scheme allows (but does not require) multiple computers that share
    a common file system to have a single IKSD database, which in turn allows
    the site manager to monitor all IKSDs on all computers at once.  This
    works if each computer has a unique IP address (which it must if they are
    on the same network sharing a common file system; nevertheless, care must
    be taken regarding IP address pools, etc).  It also depends on the file-
    sharing mechanism (such as NFS) to propogate updates promptly and in
    sequence.

 d. While one IKSD is allocating its slot, nothing prevents other IKSD
    instances that already have their own slots from updating them, since 
    that does not interfere with slot allocation.

 e. The tempfile name format is UNIXish and will need modification for file
    systems with restrictive names, such as FAT, 14-char UNIXes, etc.  In
    such cases we could (a) omit the IP address if we're not concerned about
    multiple computers sharing a single database, or (b) encode the IP
    address in Base 64 to make it shorter.  But probably none of this will
    ever come up.

 f. The design accommodates 64-bit IPv6 addresses, but for now the software
    uses only 32 bits.

7.1. Database Record Format

A slot is 4K (4096 octets), divided into 4 1K chunks.  The first chunk is
further subdivided into shorter fields.  Numeric fields are coded in
hexadecimal, right-adjusted, and left-padded with 0's.  Text fields are
left-adjusted and right-padded with blanks.  Date-time fields are
right-adjusted within a field of 18 with the leading blank reserved for Y10K.
Date-time format is:

  yyyymmdd hh:mm:ss

where yyyymmdd are the numeric year, month, and day, and hh:mm:ss are the hour
(24-hour clock), minute, and second.  Months and days are 1-based, leading 0's
are supplied where needed.

The layout of each slot is as follows (fields and byte positions are numbered
from 0):

   0. FLAGS (Slot/Session Flags)
      Start:     0
      Length:    4
      Type:   Bit Mask
      Format: Hex digits.   
      Bit Values:
       1: 1 = Slot in use, 0 = Slot is free.
       2: 1 = Real user, 0 = Anonymous user.
       4: 1 = Logged in, 0 = Not logged in.

   1. AUTHTYPE (Authorization Type)
      Start:     4
      Length:    4
      Type:   Number
      Format: Hex digits.
      Values:
       0: None          8: (reserved)
       1: Kerberos IV   9: (reserved)
       2: Kerberos V   10: LOKI
       3: SPX          11: SSA
       4: MINK         12: KEA_SJ
       5: SRP          13: KEA_INTEG
       6: RSA          14: DSS
       7: SSL          15: NTLM

   2. AUTHMODE (Authorization Type)
      Start:     8
      Length:    4
      Type:   Number
      Format: Hex digits.
      Values:
       0: Rejected
       1: Unknown
       2: Other
       3: User
       4: Valid

   3. STATE (IKSD State)
      Start:    12
      Length:    4
      Type:   Bit Mask
      Format: Hex digits.
      Bit Values:
       1: Initializing
       2: Sending a file
       4: Receiving a file
       8: Executing a REMOTE command
      32: At command prompt

   4. PID (IKSD's Process ID)
      Start:    16
      Length:   16
      Type:   Number
      Format: Hex digits.

   5. SERVER IP (IKSD's IP Address)
      Start:    32
      Length:   16
      Type:   IP address as a series of numeric octets in network byte order
      Format: Hex digits

   6. CLIENT IP (Client's IP Address)
      Start:    48
      Length:   16
      Type:   IP address as a series of numeric octets in network byte order
      Format: Hex digits

   7. SESSION START (Date and Time session started)
      Start:    64
      Length:   18
      Type:   Date-time
      Format: Date-time string

   8. LAST UPDATE (Date and Time this record was last updated)
      Start:    82
      Length:   18
      Type:   Date-time
      Format: Date-time string

   9. ULENGTH (Username length)
      Start:   100
      Length:    4
      Type:   Number
      Format: Hex digits, right adjusted

  10. DLENGTH (Length of current directory)
      Start:   104
      Length:    4
      Type:   Number
      Format: Hex digits, right adjusted

  11. ILENGTH (Length of state-specific information)
      Start:   108
      Length:    4
      Type:   Number
      Format: Hex digits, right adjusted

  12. RESERVED
      Start:   112
      Length:  912
      Type:   None
      Format: Filled with blanks

  13. USERNAME (Username; if anonymous "anonymous:<password>")
      Start:  1024
      Length: 1024
      Type:   None
      Format: Text, ULENGTH sigificant chars, right-filled with blanks

  14. DIRECTORY (Current directory)
      Start:  2048
      Length: 1024
      Type:   None
      Format: Text, DLENGTH sigificant chars, right-filled with blanks

  15. INFO (State-specific information)
      Start:  3072
      Length: 1024
      Type:   None
      Format: Text, ILENGTH sigificant chars, right-filled with blanks

The state-specific information tells you whether IKSD is at its command prompt
or in server command wait, if it is sending or receiving a file (in which case
the filename is shown), it is executing a REMOTE command (in which case the
command is shown), or how it was terminated (BYE, REMOTE EXIT, disconnect, etc)

Notes:

 a. There are no control characters (CR, LF, NUL, etc) or 8-bit
    characters; only ASCII graphic characters are used in the
    database.  Fields are left- or right-padded with Space or '0' as
    indicated.

 b. Since the USERNAME, DIRECTORY, and INFO fields are right-padded
    with spaces, it would be laborious to isolate their actual values
    by trimming spaces from the right (since we must allow for
    internal spaces); hence the ULENGTH, DLENGTH, and ILENGTH fields.

 c. The USERNAME, DIRECTORY, and INFO fields are 1K each since 1K is
    the maximum pathname length found on common UNIX platforms (even
    though many platforms have smaller maximums).  Thus, for example,
    the current directory string might be exactly 1K long.  This is why
    its length is kept outside the block.  Also the division of the
    record into four 1K blocks tends to make for more efficient i/o.
    
 d. The IKSD database does not provide a permanent record or give
    complete information.  That's what the syslog entries and the IKSD
    log are for.

7.2 The Display Module

The straightforward data definitions and formats allow a display module to be
written easily in the language of your choice, including scripting languages
such as Kermit's own.  A sample display module, iksdpy, is provided as a
"Kerbang" script, providing a running display of the active IKSD sessions from
the database.  In its startup mode, it lists each session in the database,
refreshing every 4 seconds.  Various keystroke commands are available for
help, quitting, etc, and to enter the detail screen for a specific session.
The detail screen, too, refreshes itself every 4 seconds.  Here you have keys
to return to the main screen, to pick another session, to cycle through
sessions, and so on.

When a slot is freed, its information is left intact so you can still see who
was using it, when, and from where, and the last thing they did before logging
out.  The old info persists until the slot is removed or reclaimed, which will
happen when the next new IKSD session starts.

The iksdpy script is short, simple, and easily extensible.  For example, while
watching a detail screen and you see somebody doing something bad, you might
like to have a "K" key to kill the session (the script already knows the pid,
so it need simply form a "!kill -9" command, including the pid).

7.3. Database Management

The following command-line options let you disable/enable the database and
specify its location:

--database:{on,off}
  Whether an active-sessions database should be kept.  On by default.
  If "on", but --dbfile is not specified, /var/log/iksd.db is used.

--dbfile:<filename>
  Use this option to specify an iksd database file name.  If you include 
  this option, it implies --database:on.

In UNIX, the system startup procedure can delete the database file before
starting inetd, since nothing in it is valid; however, this is not necessary
since normal cleanup procedures will do the job too.  In Windows, the IKSD
listener takes care of it.

To capture a snapshot of IKSD usage, simply copy the database file.

8. TESTING

In case you want to test IKSD on a port other than 1649, be aware that
IKS-aware Kermit clients (such as C-Kermit 7.0 and K95 1.1.18) will not
initiate Telnet negotiations with it, since it is not on a Telnet port
(i.e. 23 or 1649).  To get correct operation you'll need to force the client
to negotiate, e.g.:

  telnet hostname 3000
  set host hostname 3000 /telnet

(End of IKSD.TXT)