
UCHAN 0.1(alpha) - the *nix-Channel-Emulator

UCHAN is a collection of C-functions which implement
a subset of the "channel.h", "process.h" and "misc.h"
functionality for Transputers on *NIX hosts supporting
gcc and TCP/IP-sockets.
The purpose is to build an environment to debug processes
in a comfortable way using the gdb-debugger.
You can run processes communicating via channels on
one or on multiple hosts. 

This software is just a little hack, so don't expect
too much. The functions supported so far are:

- ChanIn(), ChanInInt(), ChanInChar(), ChanOut(), ChanOutInt(),
  ChanOutChar() (and their DirectChan... counterparts)

- ProcGetPriority(), ProcTime(), ProcAlt()

- get_param()

The functions are tested under SunOS4.1.3 and Linux 1.1.10,
but should work with most older and all newer versions.

You can compile C-programms which would normaly build LKUs.
Instead of forming one big BTL configured by a .cfs-file,
one gets executables, which can be forked by a shell-script.
So this shell-script plays the role of the configuration-
file and must provide the appropriate information.

Channels and Integers can be passed from the shell-script
to the get_param()-function by setting up some environment-
variables. Example

shell-script:
...
setenv UCPARAM_1 InChan_localhost:16601
setenv UCPARAM_2 OutChan_16602
setenv UCPARAM_3 Integer_1234
...

c-program:
...
chan1 = get_param( 1 );  /* Incomming Channel from TCP/IP-Port 16601
                            on this machine (localhost) */
chan2 = get_param( 2 );  /* Outgoing Channel to TCP/IP-Port 16602
                            (always on the local host) */
n     = get_param( 3 );  /* Pointer to Integer with value 1234 */
...


This achieves full source-code compatibility without
conditional compilation. Channels are either Input-
or Output-Channels and the size each individual message
is checked.
Every Output-Channel corresponds to a TCP-Port on the
sending machine, every Input-Channel connects to an
Output-Channel on some other machine.
When running the get_param()-function, the appropriate
environment-variables are parsed and stored in the
Channel-datastructure. The connections are established
when first calling ChanIn/ChanOut to avoid race-conditions.

The function ProcTime() returns a time messured in
64 microsecond units, but it depends on the function
ftime() and the accuracy is thus limited to
a few milliseconds :-(

-----------------------------------------------------------------------

A small example is included, which consists of a net with
one farmer and two workers. The goal is to compute
harmonic numbers by summing up the reciprocals of
natural numbers. The farmer splits the sum in little jobs
which are handed to the workers. 
For the "real" toolset do

make transputer
sumrev

For the emulation do

make all
sumrev

On both systems you should get some debug information and
then a line saying:

Sum[ 1/i, {i,1,1000000}] = 14.3927267228657
elapsed time: x.xxx seconds

If something goes wrong you will have to kill the
background worke-processes. You can fork the three
processes by hand in three different xterms, and monitor
the network activity with something like

netstat -a | grep 166

Included is a spy-process which can be used to monitor
the activity on ONE channel. If you want to monitor
more channels, you can fork more spy-processes.
The shell-script sumrev_spy shows how to fork a spy.

---------------------------------------------------------------------

Features missing so far:

- dynamic process allocation using ProcRun().
- dynamic generation of channels using ChanAlloc().
- automatic allocation of TCP/IP-ports using a routing daemon
- parsing of cfs-files

Problems so far :

- The mapping of channels to TCP/IP-ports is fixed in
  a shell-script. Under SunOS you must often wait a minute
  between two invocations of the net, because the sockets
  don't die immidiately after the jobs terminate.

- Some Sun's with cc as the system-compiler don't provide
  prototypes for functions like "connect", so "gcc -Wall"
  complains :-(


I don't know if I have the time to continue developing
UCHAN. Please mail me if you think it is usefull.
Please don't flame me for the poor, buggy and undocumented
code.

  Enjoy,  Michael

-----------------------------------------------------------
Michael Bartmann                | internet: bartmann@rog.rwth-aachen.de
Rogowski Institut RWTH-Aachen   | tel:      0241/80-7584
52062 Aachen, Schinkelstr. 2    | fax:      0241/80-7605










