Stars of Shareware: DFÜ und Kommunikation/SOS-DFUE.ISO/programm/dos/utility/pcucp101/relnotes.doc

Text File | 1993-04-22 | 11.1 KB | 224 lines

Pcucp 1.01
----------------------------------------------------------------------

A bug in terminal emulation code of the plain dos version has
been corrected. The bug sneaked in the code when I incorporated
the last changes of the Windows-version to the plain dos version.

D-pcucp now reacts to the Alt - numeric keypad codes in the usual
fashion.

If share.exe was loaded in the dos-end, the configuration files
were effectively locked while pcucp was running, since the program
failed to close the file(s) after reading them. This has now been
corrected. Because this bug was in a common source module, both
the pc- and the unix-end of the program have been slightly modified.

In the unix end, the Irix and Solaris versions have been slightly
modified.

Pcucp 1.01 is compatible with pcucp 1.00.


Pcucp 1.00
----------------------------------------------------------------------

Originally I was planning to use some variation of the user
supported software scheme for pcucp. It seems, however, that
there are at least two major problems with this : 1) Transfering
relatively small amounts of money from foreign countries seems to
cost a relatively great amount of money. 2) The local tax
authorities might decide that I must be making a gigant amount of
money with this and come up with a corresponding tax. (Which would
ruin me.) So, the software is copyrighted but free, at least for
now - I might reconsider this with future versions (if any).

I recommend the program wdial (0.99a) for dialing in the Windows
environment. For dialing in plain-dos environment I recommend
dial (1.11). Both are written by me and the current versions
can be used and copied freely.

Many thanks to the persons who tested the beta-versions of pcucp.
Also, I'd like to thank the personnel of University of Oulu for
generosly allowing me to test and develop pcucp on the various
unix-systems available there. As a result of the assistance of
these two groups, I'm confident that version 1.00 is both robust
and compatible with most unix-systems in existence.

Comments, suggestions and bug reports (with proposed fixes) are
welcome. Note, however, that I might not be able to answer
personally. (email [e-mail])


A design overwiev - how it works
----------------------------------------------------------------------

Logically, pcucp divides the serial connection to separate
channels, which are used for shells and file transfer. This
is realized trough a packet protocol that splits the data
stream to be transfered into chunks of suitable size - 'packets'.
In addition to the actual data, some control fields are included
to each packet. Most importantly, these enable data validation
in the receiving end. In case the validation fails, e.g. due
to a line error, the broken packet is resent from the remote
end until it arrives intact. The packets also carry information
about their destination channel. So, the packet protocol
effectively realizes multiple reliable logical channels on a
single unreliable serial data stream.

As soon as a packet is received and validated, an anknowledge
(ACK) is sent to the remote end. After receiving the ACK the
remote end knows that the current packet has been successfully
transfered and so it can proceed to the next. If there is no
ACK for the packet within a time limit, then the current packet
is resent periodically until an ACK arrives. Note that this
strategy also allows the ACK to be lost, provided that the
receiving end is prepared to ignore duplicates of a packet.
(This is realized by including a cyclic sequence number into
the control fields of a packet.)

The procedure described above works as such, but it tends to
waste a fraction of the line capasity, since the transmitting
end has to wait idle until the ACK arrives (or the time limit
expires). This can be corrected by using a 'sliding window'
scheme, that is, sending more packets while waiting for the
ACK for the current one. The 'sliding window' scheme realized
in pcucp uses a window size of two, that is, it sends (only)
the following packet while waiting for the ACK for the current
packet.

The ACK wait time before resending a packet is somewhat longer
than the expected time, since resending packets when not needed
would cause a severe performance hit. This results in poor
performance on noisy lines. (This is, however, inherently
related to all packet protocols, since in case of an error an
entire packet is lost. A bigger window size would help, but
in the same time compromise the interactive nature of pcucp.)

The packet protocol has a special packet type with fixed data
size. This offers a saving of 1-2 bytes in the packet header.
This saving is considerable on low communications speeds.
Because the size of the packet is fixed, the fixed packet size
definition must agree on both ends or pcucp won't work. While
PACKETSIZE in configuration file specifies the 'optimum' packet
size it also specifies the fixed packet size.

Because of the fact that in most cases the serial link to the
unix-host is not 8-bit-clean, that is, some characters more
or less mysteriosly change, totally disappear or cause special
effects, pcucp has the ability of using only a restricted range
of the 256 (=byte) codes available. This is realized through an
algorithm that codes and decodes between 8-bit bytes and the
restricted set. BITCODE keyword in configuration file specifies
how the bytes are to be converted. Since this totally changes
the interpretation of the line data, BITCODE definitions must
agree in both ends for pcucp to function at all.

A non-elegant feature of the unix-end is that the program polls its
file descriptors sleeping between polls. The elegant way, I think,
would be select(). But since I want to keep the most of the source
modules common for both the unix- and the dos-end, this is a
virtually impossible approach. The change is not even motivated by
excessive CPU load : In fact, my experience suggests that the program
is practically a zero load thing when idle. (Currently, the bsd-version
of pcucp actually uses select(), but not in the orthodox way.)


Known problems
----------------------------------------------------------------------

If the unix-host is under heavy load, pcucp might not get a change
to run often enough to keep line usage 100 % and so performance is
degraded. Giving pcucp a higher priority should help. This should
be no actual problem, since pcucp uses the CPU in short bursts at
(relatively) long intervals and so most of the CPU time would be
free for other processes. The hard part here is that you need to
convince your unix-operator to do this for you :-)

Note that even in 386 Enchanced mode pcucp's performance in file
transfer is severely degraded if a dos application is executing
in the foreground. In standard (and real) mode pcucp is completely
stopped when a dos application is used. In 386 Enchanced mode, it
might help to set the Windows background priority to a higher value,
or maybe use a dos box with a low priority.

It seems that transfering files in both directions at once
causes a performance hit. This is due to the fact that ACK-
packets race with the constantly flowing data packets and thus
an unnecessary delay is generated between sending data packets.
So far, I haven't been able to figure out an actual fix for
this (without compromising the interactive nature of the packet
protocol).

For some reason file transfer from the pc-end is somewhat slower
than that from the unix-end. The only reason I can think of is
that the unix-end's response time is somewhat longer than that of
the pc-end. This is actually true for the posix/sysv-versions
since the sleep time between polls is constant (100 ms) and
longer than that in the pc-end (55 ms). The bsd-version with
the 'synchronized sleep' realized with select() should fix this,
but it seems not to (?).

I have the impression that a vt100 terminal has autowrap on by
default. It seems, however, that some programs (such as vi) do
not work correctly with this. Hence the default is no autowrap.
This can be changed by echoing the autowrap-on command string
on the emulated terminal in e.g. the .cshrc file. On systems
with a sysv-style, standalone echo-command with octal escapes
this could be done with /bin/echo "\033[?7h".

In a typical case the connection to the unix-host is realized
trough a device that connects to the pc trough a serial line
and to the unix-host trough a local network. In the following
discussion such a device is known as a 'bridge'. The unfortunate
thing about bridges is that they are not likely to be 8-bit-clean
and hence BITCODE must be used to deal with them, which decreases
the effective line speed. Also, the bridge usually not only
distorts the data but also takes special actions on some character
codes such as C-s, which might cause any output from the bridge
to the pc to stop until a C-q is received by the bridge. Also, there
might be a 'bridge escape' code which causes 'dropping back' to the
bridge prompt from the unix-session. These are (more or less) useful
in the usual case, but not too nice for a pcucp user, since any
special action like this causes the connection to be effectively
severed. BITCODE helps to keep out of trouble most of time, but it
can't help such special codes not to be generated by line errors.
This is where the configuration setting SALVSTR comes in. This string
is sent over the communications when the remote end has stopped
responding in order to command the bridge to resume a broken session.
Of course, this might not be enough to salvage the connection in all
cases (or maybe not with all bridges either), but it is a simple measure
which should be useful in most (?) cases.

When SALVSTR was introduced I also had to make sure that any packets
echoed by the bridge when a connection is broken would not be seen as
valid packets coming from the remote end. This was done by modifying
the packet checksum algorithm in a way depending on the string returned
by the gethostname() function. Since this function is emulated in the
pc-end by returning 'PC', an unix-host named 'PC' will not work with
pcucp.


Future plans
----------------------------------------------------------------------

I would like to write new and better versions of pcucp in the
future, but then again, studying and making a living may not
leave enough time for this.

The following features should be in version 1.1 :

  - resizeable terminal windows
  - cut & paste
  - scrollback buffer
  - on-line help

When writing this, it seems probable that the plain-dos version
of pcucp will not be supported in the future, or at least the
conversion will take place only after the Windows-version is
about complete. All features of the future Windows-version might
not be in the dos-version. The focus is on the Windows-version,
since Windows as an environment is inherently more suitable for
a program like pcucp. Also, concentrating on the Windows-version
increases the odds of version 1.1 to be released at all.