ckubwr.txt

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

longer time.  For example, the "hpux100o+" makefile entry adds the "+Onolimit"
compiler flag, and about an hour to the compile time on an HP-9000/730.  But
it *does* produce an executable that is about 10K smaller :-)

In the C-Kermit 7.0 makefile, all HP-UX entries automatically skip
optimization of problematic modules.

3.2.2. Performance

An unexpected slowness has been noted when transferring files over local
Ethernet connections when an HP-UX system (9.0 or later, perhaps also earlier
versions) is on the remote end.   The following experiment was conducted to
determine the cause.  C-Kermit 6.0 was used; the situation is slightly better
using C-Kermit 7.0's streaming feature.

The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20), both
on the same local 10Mbps Ethernet, packet length 4096, parity none, control
prefixing "cautious", using only local disks on each machine -- no NFS.  In
the C-Kermit 6.0 (ACK/NAK) case, the window size was 20; in the streaming case
there is no window size.  The test file was C-Kermit executable, transferred
in binary mode.  Conditions were relatively poor: the Sun and the local net
heavily loaded; the HP system is old, slow, and memory-constrained.

                   C-Kermit 6.0...    C-Kermit 7.0...
 Local    Remote   ACK/NAK........    Streaming......
 Client   Server   Send    Receive    Send    Receive
  Sun      HP       36       18        64       18
  HP       HP       25       15        37       16
  HP       Sun      77       83       118       92
  Sun      Sun      60       60       153      158

So whenever HP is the remote we have poor performance.  Why?

 . Changing file display to CRT has no effect (so it's not the curses
   library on the client side).

 . Changing TCP RECV-BUFFER or SEND-BUFFER has little effect.

 . Telling the client to make a binary-mode connection (SET TELNET BINARY
   REQUESTED, which successfully negotiates a binary connection) has no
   effect on throughput.

BUT...  If I start C-Kermit as a TCP server:

  set host * 3000
  server

and then from the client "set host blah 3000", I get:

                   C-Kermit 6.0...    C-Kermit 7.0...
 Local    Remote   ACK/NAK........    Streaming......
 Client   Server   Send    Receive    Send    Receive
  Sun      HP       77       67       106      139
  HP       HP       50       50        64       62
  HP       Sun      57       85       155      105
  Sun      Sun      57       50       321      314

Therefore the HP-UX telnet server or pty driver seems to be adding more
overhead than the SunOS one, and most others.  When going through this type of
connection (a remote telnet server) there is little Kermit can do improve
matters, since the telnet server and pty driver are between the two Kermits,
and neither Kermit program can have any influence over them (except putting
the Telnet connection in binary mode, but that doesn't help).

(The numbers for the HP-HP transfers are lower than the others since both
Kermit processes are running on the same slow CPU.)

3.2.3. Dialing Out and UUCP Lockfiles in HP-UX

Before you can use serial ports on the HP-9000, you must configure them as
either "terminals" or "modems" with SAM ("peripheral devices"..."terminals and
modems"), as described in the HP manual, "Configuring HP-UX for Peripherals:
HP 9000".  If you attempt to use a serial device before it has been configured
this way, it will not work properly; typical symptoms are (a) no communication
at all; (b) nonfunctional modem signals; and/or (c) massive amounts of
character loss in both directions.

In HP-UX 9.0, serial device names began to change.  The older names looked
like "/dev/cua00", "/dev/tty01", etc (sometimes with only one digit).
The newer names have two digits with the letter "p" in between.  HP-UX 8.xx
and earlier have the older form, HP-UX 10.00 and later have the newer form.
HP-UX 9.xx has the newer form on Series 800 machines, and the older form on
other hardware models.  The situation is summarized in the following table:

  Converged HP-UX Serial I/O Filenames : TTY Mux Naming
  ---------------------------------------------------------------------
  General meaning      Old Form     S800 9.0           Convio 10.0
  ---------------------------------------------------------------------
  tty* hardwired ports  tty<YY>     tty<X>p<Y>         tty<D>p<p>
		                    diag:mux<X>        diag:mux<D>
  ---------------------------------------------------------------------
  ttyd* dial-in modems  ttyd<YY>    ttyd<X>p<Y>        ttyd<D>p<p>
		                    diag:ttyd<X>p<Y>   diag:ttyd<D>p<p>
  ---------------------------------------------------------------------
  cua* auto-dial out    cua<YY>     cua<X>p<Y>         cua<D>p<p>
		                    diag:cua<X>p<Y>
  ---------------------------------------------------------------------
  cul* dial-out         cul<YY>     cul<X>p<Y>         cul<D>p<p>
		                    diag:cul<X>p<Y>
  ---------------------------------------------------------------------
   <X>= LU (Logical Unit)  <D>= Devspec (decimal card instance)
   <Y> or <YY> = Port      <p>= Port

For dialing out, you should use the cua or cul devices.  When C-Kermit's
CARRIER setting is AUTO or ON, C-Kermit should pop back to its prompt
automatically if the carrier signal drops, e.g. when you log out from the
remote computer or service.  If you use the tty<D>p<d> (e.g. tty0p0) device,
the carrier signal should be ignored.  The tty<D>p<d> device should be used
for direct connections where the carrier signal does not follow RS-232
conventions (use the cul device for hardwired connections through a true null
modem).  Do not use the ttyd<D>p<d> device for dialing out.

Kermit's access to serial devices is controlled by "UUCP lockfiles", which are
intended to prevent different users using different software programs (Kermit,
cu, etc, and UUCP itself) from accessing the same serial device at the same
time.  When a device is in use by a particular user, a file with a special
name is created in:

  /var/spool/locks  (HP-UX 10.00 and later)
  /usr/spool/uucp   (HP-UX 9.xx and earlier)

The file's name indicates the device that is in use, and its contents
indicates the process ID (pid) of the process that is using the device.  Since
serial devices and the locks directory are not both publicly readable and
writable, Kermit and other communication software must be installed setuid to
the owner (bin) of the serial device and setgid to the group (daemon) of the
/var/spool/locks directory.  Kermit's setuid and setgid privileges are enabled
only when opening the device and accessing the lockfiles.

Let's say "unit" means a string of decimal digits (the interface instance
number) followed (in HP-UX 10.00 and later) by the letter "p" (lowercase),
followed by another string of decimal digits (the port number on the
interface), e.g.:

  "0p0", "0p1", "1p0", etc       (HP-UX 10.00 and later)
  "0p0", "0p1", "1p0", etc       (HP-UX 9.xx on Series 800)
  "00",  "01",  "10",  "0", etc  (HP-UX 9.xx not on Series 800)
  "00",  "01",  "10",  "0", etc  (HP-UX 8.xx and earlier)

Then a normal serial device (driver) name consists of a prefix ("tty", "ttyd",
"cua", "cul", or possibly "cuad" or "culd") followed by a unit, e.g. "cua0p0".
Kermit's treatment of UUCP lockfiles is as close as possible to that of the
HP-UX "cu" program.  Here is a table of the lockfiles that Kermit creates for
unit 0p0:

  Selection      Lockfile 1     Lockfile 2
  ------------   ------------   ------------
  /dev/tty0p0    LCK..tty0p0    (none)
* /dev/ttyd0p0   LCK..ttyd0p0   (none)
  /dev/cua0p0    LCK..cua0p0    LCK..ttyd0p0
  /dev/cul0p0    LCK..cul0p0    LCK..ttyd0p0
  /dev/cuad0p0   LCK..cuad0p0   LCK..ttyd0p0
  /dev/culd0p0   LCK..culd0p0   LCK..ttyd0p0
  <other>        LCK..<other>   (none)

(* = Dialin device, should not be used.)

In other words, if the device name begins with "cu", a second lockfile for
the "ttyd" device, same unit, is created, which should prevent dialin access
on that device.

The <other> case allows for symbolic links, etc, but of course it is not
foolproof since we have no way of telling which device is really being used.

When C-Kermit tries to open a dialout device whose name ends with a "unit", it
searches the lockfile directory for all possible names for the same unit.  For
example, if user selects /dev/cul2p3, Kermit looks for lockfiles named:

  LCK..tty2p3
  LCK..ttyd2p3
  LCK..cua2p3
  LCK..cul2p3
  LCK..cuad2p3
  LCK..culd2p3

If any of these files are found, Kermit opens them to find out the ID (pid) of
the process that created them; if the pid is still valid, the process is still
active, and so the SET LINE command fails and the user is informed of the pid
so s/he can use "ps" to find out who is using the device.

If the pid is not valid, the file is deleted.  If all such files (i.e. with
same "unit" designation) are successfully removed, then the SET LINE command
succeeds; up to six messages are printed telling the user which "stale
lockfiles" are being removed.

When the "set line" command succeeds in HP-UX 10.00 and later, C-Kermit also
creates a UNIX System V R4 "advisory lock" as a further precaution (but not
guarantee) against any other process obtaining access to the device while
you are using it.

If the selected device was in use by "cu", Kermit can't open it, because "cu"
has changed its ownership, so we never get as far as looking at the lockfiles.
In the normal case, we can't even look at the device to see who the owner is
because it is visible only to its (present) owner.  In this case, Kermit says
(for example):

  /dev/cua0p0: Permission denied

When Kermit releases a device it has successfully opened, it removes all the
lockfiles that it created.  This also happens whenever Kermit exits "under its
own power".

If Kermit is killed with a device open, the lockfile(s) are left behind.  The
next Kermit program that tries to assign the device, under any of its various
names, will automatically clean up the stale lockfiles because the pids they
contain are invalid.  The behavior of cu and other communication programs
under these conditions should be the same.

3.2.4. HP-UX 5.00

The HP-UX 5.00 version of C-Kermit does not include the fullscreen
file-transfer because of problems with the curses library.

If HP-UX 5.21 with Wollongong TCP/IP is on the remote end of a Telnet
connection, streaming transfers to HP-UX invariably fail.  Workaround:
SET STREAMING OFF.  Packets longer than about 1000 should not be used.
Transfers from these systems, however, can use streaming and/or longer
packets.

Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on the
HP-9000 series 500 computers.  It only occurs when the controlling terminal
is using an HP-27140 six-port modem mux.  The problem is not present if the
controlling terminal is logged into an HP-27130 eight-port mux.  The symptom
is that just after dialing successfully and connecting Kermit locks up and
the port is unusable until both forks of Kermit and the login shell are
killed."  (This report predates C-Kermit 6.0 and might no longer apply.)

3.2.5. HP-UX 8.00

To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install HP-UX
patch PHNE_0899.  This patch deals with a lot of driver issues, particularly
related to communication at higher speeds.

And this report just in:

"On HP-UX 8 DON'T install 'tty patch' PHKL_4656, install PHKL_3047 instead!
Yesterday I tried this latest tty patch PHKL_4656 and had terrible problems.
This patch should fix RTS/CTS problems. With text transver all looks nice.
But when I switched over to binary files the serial interface returned only
rubish to C-Kermit. All sorts of protocol, CRC and packed errors I had. After
several tests and after uninstalling that patch, all transvers worked fine.
MB's of data without any errors.  So keep your fingers away from that patch.
If anybody needs the PHKL_3047 patch I have it here. It is no longer availabel
from HP's patch base."

3.2.6. HP-UX 9.00 AND LATER

HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces PHNE_3641)
for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a.  Contact Hewlett Packard
if you need this patch.  Without it, the dialout device (tty) will be hung
after first use; subsequent attempts to use will return an error like "device
busy".  (There are also equivalent patches for s700 9.03 9.05 9.07
(PHNE_10573) and s800 9.00 9.04 (PHNE_10416).

When C-Kermit is in server mode, it might have trouble executing REMOTE HOST
commands.  This problem happens under HP-UX 9.00 (Motorola) and HP-UX 9.01
(RISC) IF the C-Shell is the login shell AND with the C-Shell Revision 70.15.
Best thing is to install HP's Patch PHCO_4919 for Series 300/400 and PHCO_5015
for the Series 700/800.  PHCO_5015 is called "s700_800 9.X cumulative csh(1)
patch with memory leak fix" which works for HP-UX 9.00, 9.01, 9.03, 9.04, 9.05
and 9.07.  At least you need C-Shell Revision 72.12!

C-Kermit works fine -- including its curses-based file-transfer display -- on
the console terminal, in a remote session (e.g. when logged in to the HP 9000
on a terminal port or when telnetted or rlogin'd), and in an HP-VUE hpterm
window or an xterm window.

3.2.7. HP-UX 10.10 AND LATER