Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next  

RFC 0809

UCL facsimile system

Pages: 99
Group: ~tcp
Part 2 of 3 – Pages 30 to 59
First   Prev   Next

ToP   noToC   RFC0809 - Page 30   prevText
       In order to implement  this  strategy,  each  time  a
     piece  of  data  is  required,  the  size of the buffer
     needed is compared with that of the unused buffer  area
     in  the current CSB. If the latter is not less than the
     former,  the  current  buffer  pointer   is   returned.
     Otherwise,  a  temporary buffer has to be employed. The
     data is copied into the buffer until the requested size
     is  reached.  In  this  case,  instead of a part of the
     current buffer, the temporary buffer will be returned.

       A 'cswrite' call with the 'need' field  set  to  zero
     tells  the  interface routine that no more data will be
     sent. It causes  a  'close'  CSB  to  be  sent  to  the
     destination routine.

       If there  is  not  enough  data  available,  'csread'
     returns zero to indicate the end of data.


       Now we discuss the implementation of the computerised
     facsimile   system   developed  in  the  Department  of
     Computer Science at UCL.

       This system has several components. Since  the  total
     system  is  a modular and multi-process one, a specific
     system must be built up for a specific application. The
     way  that this is done is discussed in section 4.1. The
     specific devices and their  drivers  are  described  in
     section  4.2. The system can be attached to a number of
     networks.  In  the  UCL  configuration,   the   network
     interface  can be direct to SATNET [22], SERC NET [23],
     PSS [24], and the Cambridge Ring. The form  of  network
     connection  is  discussed  further  in section 4.3. The
     system must transfer data between the facsimile devices
     and  the disks, and between the networks and the disks.
     For this a filing system is required which is discussed
     in section 4.4.

       A key aspect of the  UCL  system  is  flexibility  of
     devices, networks, and data formats. The flexibility of
     device is achieved by the modular nature of the  device
     drivers  (section  4.2).  The flexibility of network is
     discussed in section 4.8. The additional flexibility of
     data   structure  is  described  in  section  4.5.  The
     flexibility can be utilised by incorporating conversion
     routines  as in section 4.6. An important aspect of the
     UCL system is the ability to provide local manipulation
     facilities  for  the  graphics  files.   The facilities
     implemented for the local manipulation are discussed in
ToP   noToC   RFC0809 - Page 31
     section 4.7.  In  order  to  transfer  files  over  the
     different  networks  of  section 4.3. a high level data
     transmission protocol must be defined.  The  procedures
     used in the UCL system are discussed in section 4.8.

     4.1 Multi-Task Structure

       The  task  controller  and   processing   tasks   are
     implemented  as  MOS  processes.  A  number  of utility
     routines are provided  for  users  to  build  new  task
     processes and modules at application level.

       In the environment of MOS, a process is included in a
     system  by  specifying a Process Control Table when the
     system is built up. The macro  'setpcte'  is  used  for
     this  purpose,  the  meaning  of  its  parameters being
     defined in [14].

     #define setpcte(name,entry,pridev,prodev,stklen,

       A Device Control Table (DCT) has to be specified  for
     each  device  when the system is built up. A DCT can be
     defined anywhere as devices are referenced by  the  DCT
     address.  The  macro  'setdcte'  is designed to declare
     devices, the meanings of its parameters being specified
     in   [14].    This   method   is  used  in  the  device

     #define setdcte(name,intvec,devcsr,devbuf,devinit,

     4.2 The Devices

       As mentioned in section 2,  apart  from  the  general
     purpose  system console, there are three devices in the
     system to support the facsimile service. These are:

      (1) AED62 Floppy Disk, which is used as the  secondary
          memory storing the facsimile image data. Above its
          driver, a file system is implemented to manage the
          data  stored  on  the disks, so that an image data
ToP   noToC   RFC0809 - Page 32
          file can be accessed through the Clean and  Simple
          interface.  This file system is dicussed in detail
          in the next section. For some processing jobs, the
          image  data  has  to  buffered on a temporary file
          lest time-out occurs on the facsimile machine.

      (2) DACOM Facsimile Machine, which is  used  to  input
          and  output  image  data.  It  reads  an image and
          creates the corresponding data  stream.  On  other
          hand, it accepts the image data and reproduces the
          corresponding image. Above its driver, there is  a
          interface  task  to fit the facsimile machine into
          the system, the Clean and Simple  interface  being
          supported.   The  encoding algorithm for the DACOM
          machine is described in [19].

      (3) Grinnell Colour Display,  which  is  used  as  the
          monitor  of  the  system.  Above  its  driver,  an
          interface task is implemented so  that  the  image
          data  in  standard  format can be accepted through
          the Clean and Simple interface.

       The detailed description  of  these  devices  can  be
     found  in  Appendix  1.  The  interface  task  and  the
     description for each device are listed in the following
     table. The interface tasks can be directly used as data
     source or sink in a task string.

           Device       Interface Task  Description

     AED62 Floppy Disk        fs()      aed62(device)
     DACOM fax Machine       fax()      dacom(device)
     Grinnell Display   grinnell()      grinnell(device)

       Note that the DCTs  for  the  facsimile  machine  and
     Grinnell    display   have   been   included   in   the
     corresponding interface tasks, so that there is no need
     to declare them if these tasks are used.

     4.3 The Networks

       There   are   three   relevant   wide-area   networks
     terminating  in  the  Department of Computer Science at
     the end of 1981. These are:

      (1) A British Telecom X25 network (PSS, [24]).

      (2) A private X25 network (SERC NET, [23])
ToP   noToC   RFC0809 - Page 33
      (3) A Defence network (ARPANET/SATNET, [21], [22])

       In addition there is a  Cambridge  Ring  as  a  local

       For the time  being,  the  UCL  facsimile  system  is
     directly  attached to the various networks at the point
     NI (Network Interface) of Fig. 1.

       As mentioned earlier, pictures can be  exchanged  via
     the  SATNET/ARPANET,  between UCL in London, ISI in Los
     Angeles, and COMSAT in  Washington  D.C..  The  Network
     Independent File Transfer Protocol (NIFTP, [9]) is used
     to transfer the image data.   This  protocol  has  been
     implemented  on LSI under MOS [10].  In addition, we at
     UCL have put NIFTP on an ARPANET  TOPS-20  host,  which
     can  act  as  an Internet File Forwader (IFF).  In this
     case, TCP/IP ([28], [29]) is employed as the underlying
     transport   service.   Since   TCP   provides  reliable
     communication channels, the  provision  of  checkpoints
     and  error-recovery  procedures are not included in our
     NIFTP implementations.

       In  the  X25  network,  the  transport  procedure  is
     NITS/X25   ([25],   [26]).    Though  pictures  can  be
     transferred to the X25 networks, no  experimental  work
     has been done, because:

      (1) There is at present no  collaborative  partner  on
          these networks.

      (2) The LSI-11, on which our  system  is  implemented,
          has no direct connection to these networks.

       Locally,  image  data  can  be  transmitted  to   the
     PDP11-44s   running  the  UNIX  time-sharing  operating
     system. At present, the SCP ring-driver  software  uses
     permanent   virtual  circuits  (PVCs)  to  connect  the
     various computers on the ring.

     4.4 File System

       A file system has been designed, based on  the  AED62
     double  density  floppy  disk, for use under MOS. It is
     itself implemented as  a  MOS  process  supporting  the
     Clean  and  Simple  interface.  The description of this
     task, fs(fax), can be found in Appendix 2.
ToP   noToC   RFC0809 - Page 34
       In a command string, the file system  task  can  only
     serve  as  either  data  source  or data sink. In other
     words, it can only appear at the first or last position
     on  a  command  string.  In  the  former case, the file
     specified is to be  read,  while  the  file  is  to  be
     written in the latter case.

       Three access modes are allowed which are:

       * Read a file
       * Create a file
       * Append a file

       The file name and access mode are  specified  as  the
     open parameters.

       Let us consider an example.  If a document is  to  be
     read  on  the  facsimile  machine  and  the data stream
     created is to be stored on the file system, the command
     string required is:


     where:  fax - interface task for facsimile machine
             r   - read from facsimile machine
             fs  - file system task
             c   - create a new file
             doc - the name of the file to be created.

       In order to dump a  file,  a  task  process  od()  is
     provided  which  works  as  a  data  sink  in a command

     4.5 Data Structure

       Facsimile  image  data  is  created  using  a   high-
     resolution raster scanner, so that the original picture
     can  be  reproduced  faithfully.  The  facsimile   data
     represents  binary  images,  in  monochrome,  with  two
     levels of intensity, belonging  to  the  data  type  of
     bit-mapped graphics.

       The simplest representation is  the  bit-map  itself.
     The bits, each of which corresponds to a single picture
     element, are arranged in the  same  order  as  that  in
     which  the original picture is scanned, 1s standing for
ToP   noToC   RFC0809 - Page 35
     black pixels and 0s for white ones. Operations  on  the
     picture are easily carried out. For example, two images
     represented  in  the  bit-map  format  can  be   merged
     together  by  using  a  simple  logic OR operation. Any
     specific  pixel  can   be   retrieved   by   a   simple
     calculation. However, its size is usually large because
     of  the  high  resolution.   This   makes   it   almost
     unrealistic for storage or transmission.

       Facsimile image data should therefore  be  compressed
     to reduce its redundancy, so that the efficient storage
     and transmission can be achieved.

       Run-length encoding is a useful  compression  scheme.
     Instead of the pattern, the counts of consecutive black
     and white runs are used to represent the image.

       Vector representation, in which the  run-lengths  are
     coded  as  integers  or  bytes,  is  a  useful internal
     representation of images. Not  only  is  it  reasonably
     compressed,  but  it is also quite easy for processing.
     Chopping, scaling and mask-scanning are examples of the
     processing   operations   which   may   be   performed.
     Furthermore, a conversion between different compression
     schemes  may  have to be carried out in such a way that
     the data is first decompressed into the  vector  format
     and  then recompressed. The difficulty in retrieval can
     be overcome by means of line  index,  which  gives  the
     pointers to each lines of the image.

       A higher compression rate leads to a  more  efficient
     transmission.  But  this  is  at the expense of ease of
     processing.  An example of this is the use  of  Huffman
     Code  in  the  CCITT  1-dimensional compression scheme.
     While the data can be compressed more  efficiently,  it
     is rather difficult to manipulate the data direcltly.

       Taking the correlation between  adjacent  lines  into
     account,  2-dimensional compression can achieve an even
     higher   compression    rate.    CCITT    2-dimensional
     compression  and  the  DACOM facsimile machine use this

       It is desirable to integrate  facsimile  images  with
     other  data types, such as text and geometric graphics;
     the  structure  of  these  other  types  must  then  be
     incorporated  in  the  system.  At  present,  only text
     structure  is  available,  while  the   structure   for
     geometric graphics is a topic for the further study.
ToP   noToC   RFC0809 - Page 36
       In  the  facsimile   system,   the   following   data
     structures    are    supported.    The    corresponding
     descriptions, if any, are listed as well and  they  can
     be found in Appendix 3 (except of dacom(device)).

     type    structure       compression     description

     bit-map  bit-map               -              -
             vector          1D run-length   vector(fax)
             dacom block     2D run-length   dacom(device)
             CCITT T4        1D run-length   t4(fax)
                             2D run-length   t4(fax)

     text    text                  -         text(fax)

       As an  internal  data  structure,  vector  format  is
     widely  used  for data transfer between task processes.
     The set of interface  routines  has  been  extended  by
     introducing  two subroutines, namely getl() and putl(),
     which read and write line vectors directly through  the
     Clean  and  Simple interface. These two routines can be
     found in Appendix 3 (getl(fax) and putl(fax))

       In order to check the validity of a  vector  file,  a
     check task process check() is provided which works as a
     data sink in a command string. It  can  also  dump  the
     vector elements of the specific lines.

     4.6 Data Conversion

       In order to convert one data structure into  another,
     several conversion modules are provided in this system.
     These modules fall into two categories, task  processes
     and  subroutines.  The task processes are MOS processes
     which can only be used in the environment described  in
     this note, while the subroutines which are written in c
     and compatible under UNIX are more generally usable.

       Character strings  or  text  can  be  converted  into
     vector  format,  so  that an integrated image combining
     picture and text can be formed.

       The following table lists these  conversion  modules,
     including  their  functions and descriptions (which can
     be found in Appendix 3).
ToP   noToC   RFC0809 - Page 37
     module  type          from          to      description

     decomp  process       dacom         vector   decomp(fax)
     recomp  process       vector        dacom    recomp(fax)

     ccitt   process       vector        t4       ccitt(fax)
                           t4            vector

     bitmap  subroutine    vector        bitmap    bit-map(fax)
     tovec   subroutine    bitmap        vector    tovec(fax)

     ts      subroutine    ASCII string  vector   ts(fax)
     string  process       ASCII string  vector   string(fax)
     tf      process       text          vector   tf(fax)

       Since each DACOM block contains a  Cyclic  Redundancy
     Check  (CRC)  field,  the  system supplies a subroutine
     crc()  to  calculate  or  check  the  CRC  code.   (see

       If a vector file  is  to  be  printed  on  the  DACOM
     facsimile   machine,  the  image  data  should  be  re-
     compressed into the DACOM-block  format,  the  required
     command string being shown below.


     where   fs     - file system task
             e      - read an existing file
         ic    - file name
             recomp - re-compression task
             fax    - interface task for facsimile machine
             w      - print an image on facsimile machine

     4.7 Image Manipulation

       Four processing task processes are  provided  in  the
     system.  These are:

      (1) Chop, which applies a defined window to the  input

      (2) Scale, which enlarges or shrinks the  input  image
          to the defined dimensions.

      (3) Merge, which puts the input image on the specified
          area of a background image.
ToP   noToC   RFC0809 - Page 38
      (4) Clean, which removes the noise on the input image.

       The Clean and  Simple  interfaces  are  supported  in
     these processing tasks so that the tasks can be used in
     command strings.  However, these tasks can  be  neither
     source  nor  sink in a command string.  The data format
     of their input and output is vector.

       For example, a facsimile page can be cleaned and then
     printed  on  the facsimile machine. Note that the image
     data must be recompressed  before  being  sent  to  the
     facsimile  machine. If the original data is the form of
     DACOM  block,  it  has  to  be  decompressed   as   the
     processing   tasks   only  accept  line  vectors.   The
     required command string is shown below.


     where   fs     - file system task
             e      - read an existing file
             page   - file name
             clean  - cleaning task
             recomp - re-compression task
             fax    - interface task for facsimile machine
             w      - print an image on facsimile machine

       The descriptions of these  processing  tasks  can  be
     found in Appendix 2 (chop(fax), scale(fax), merge(fax),
     and clean(fax)).

       In tasks 'chop' and  'merge',  a  window  is  set  by
     giving  the coordinates of its vertices. However, it is
     usually rather difficult for a human user to decide the
     exact  coordinates.  The  system  supplies a subroutine
     choice() which specifies a rectangular subsection of an
     image  by  interactive  manipulations  of a rectangular
     subsection  on  the  screen  of  the  Grinnell  display
     displaying the image.  It provides a set of interactive
     commands whereby a user can intuitively choose an  area
     he  is interested in. Note that this subroutine must be
     called by a MOS process and the Grinnell  display  must
     be included in the system.

       By means of these image processing modules, the image
     editing  described  in  section 2.4 can be carried out.
     Let us consider an example. An image abstracted from  a
     picture  'a'  is  to be merged onto a specified area of
     another picture 'b'. First of all, the two pictures 'a'
ToP   noToC   RFC0809 - Page 39
     and 'b' should be displayed on the left half and  right
     half  of  the screen, respectively. Assume that the two
     pictures are standard DACOM pages whose dimensions  are
     1726x1200.  They have to be shrunk to fit the dimension
     of the half screen (256x512).  Note that  if  the  data
     format  is not vector, conversion should be carried out
     first.  the required command strings are:


     where   fs            - file system task
             e             - read an existing file
             a             - file name
             b             - file name
             scale         - scale task
             1726,1200     - old dimension
             256,512       - new dimension
             grinnell       - grinnell display interface task
             0,511,255,0   - presentation area (the left half)
             256,511,511,0 - presentation area (the right half)
             z             - zero write mode
             g             - green
             b             - blue

       In an application process, the subroutine choice() is
     called in the following ways for the user to choose the
     areas on both pictures.
ToP   noToC   RFC0809 - Page 40
     choice(r, 1726, 1200, 1, 0, 0);
             /* choice the area on 'a' */
             /* r    - red
                1726 - width of the original picture
                1200 - height of the original picture
                1    - left half of the screen
                0    - the subsection can be of any width
                0    - the subsection can be of any height
     choice(r, 1726, 1200, 2, 0, 0);
             /* choice the area on 'b' */
             /* r    - red
                1726 - width of the original picture
                1200 - height of the original picture
                2    - right half of the screen
                0    - the subsection can be of any width
                0    - the subsection can be of any height

       When the user finishes editing,  the  coordinates  of
     the  chosen  rectangular areas are returned. An example
     is given in the table below.  The  widths  and  heights
     listed  in  the  table are actually calculated from the
     coordinates returned and they indicate that the  source
     image has to be enlarged to fit its destination.

              (0, 0)
                +-------------------------------> x
                |  (x0, y0)     w
                |     +--------------------+
                |     !                    !
                |     !                    !
                |     !                    ! h
                |     !                    !
                |     !                    !
                |     +--------------------+
                |                       (x1, y1)

     original   x0      y0      x1      y1      w       h

        a       30      40     100     120      70      80
        b      100     100    1100    1100    1000    1000
ToP   noToC   RFC0809 - Page 41
       At this stage, our final  goal  can  be  achieved  by
     performing  a  job  specified below. It is assumed that
     the result image is to be stored as a new file 'c'.


     where   fs                - file system task
             e                 - read an existing file
             a                 - file name
             chop              - chop task
             30,40,100,120     - the area to be abstracted
             scale             - scale task
             70,80             - old dimension
             1000,1000         - new dimension
             merge             - merge task
             b                 - file name of the background image
             0                 - to be overlaid
             100,100,1100,1100 - the area to be overlaid
             fs                - file system task
             c                 - create a new file
             c                 - the name of the file to be

     4.8 Data Transmission

       In  order  to  transmit  facsimile  image  data  over
     computer  networks,  using the configuration of Fig. 1,
     the Network Independent File Transfer Protocol  [9]  is
     implemented as a MOS task process, the Clean and Simple
     interface of section 3.3  being  supported  [10].  Thus
     this  module  can be used in a command string directly.
     In this case, the module always works in the  initiator
     mode,  though the server mode is supported as well. Its
     description can be found in Appendix 2 (ftp(fax)).

       As  a  network-independent  protocol,  it  employs  a
     transport  service  to communicate across the networks.
     The Clean and Simple interface is  also  used  for  the
     communication  between the module and transport service

       Suppose that an image file stored in  a  remote  file
     system is to be printed on the local facsimile machine.
     Assume that the data is  transmitted  via  the  ARPANET
     [21],  Transport Control Protocol (TCP) [28] being used
     as the underlying transport service. As  was  described
ToP   noToC   RFC0809 - Page 42
     before, since the  delay  caused  by  the  network  may
     result  in  a  time-out on the local facsimile machine,
     the job should be divided into two subjobs.

      (1) The remote file  is  transmitted  by  using  NIFTP
          module.   However,  instead  of  being  put on the
          facsimile machine directly, the received  data  is
          store in a temporary file.


          where   ftp - NIFTP task
                  t   - receive
                  b   - binary
                  ucl - remote user name
                  fax - remote password
                  pic - remote file name
                  tcp - transport service process

                  parameters for the transport service:

                      1234      - local channel number
                      10,3,3,42 - remote address
                      4521      - channel reserved for the
                                  remote server

                  fs  - local file system task
                  c   - create a new file
                  tmp - the name of the file to be created

      (2) The temporary file is read and the image  is  sent
          to  the facsimile machine for printing. Here it is
          assumed the data received is in the form of  DACOM
          block so that no conversion is needed.


          where   fs     - file system task
                  e      - read an existing file
                  tmp    - file name
                  fax    - interface task for facsimile machine
                  w      - print an image on facsimile machine

       We are able to  exchange  image  data  with  ISI  and
     COMSAT.  At present DACOM block is the only format that
     can be used as  all  the  three  participants  in  this
     experiment  possess  DACOM  facsimile  machines  and no
ToP   noToC   RFC0809 - Page 43
     other data format is available in both ISI and  COMSAT.
     However,  it  is  the  intention  of the ARPA-Facsimile
     community to adopt the CCITT standard for future  work.
     As mentioned earlier, UCL already has this facility.

       Above NIFTP, a simple protocol was  used  to  control
     the  transmission  of facsimile data. In this protocol,
     the format of a facsimile  data  file  was  defined  as
     follows:  Each  DACOM  block was recorded with a 2-byte
     header at the front. This  header  was  composed  of  a
     length-byte   indicating   the   length  of  the  block
     (including the header) and a code-byte  indicating  the
     type  of  the  block.  This  is  shown in the following

             |<--- header ---->|<------ 74 bytes ------->|
             ! length !  code  !       DACOM block       !

       The Length-byte is 76 (decimal) for all DACOM blocks.
     The  code-byte for a setup block is 071 (octal) and 072
     for a data block. A  special  EOP  block  was  used  to
     indicate  the  end  of  a page. This block had only the
     header with the length-byte set to 2 and the  code-byte
     undefined.  A facsimile data file could contain several
     pages, which were separated by EOP blocks.


     5.1 Summary

       Though techniques  for  facsimile  transmission  were
     invented  in  1843,  it  was not until the recent years
     that integration with  computer  communication  systems
     gave rise to "great expectation".  The system described
     in  this  note   incarnates   the   compatibility   and
     flexibility of computerised facsimile systems.

       In this system, facsimile no longer refers simply  to
     the  transmission device, but rather to the function of
     transferring hard copy from one place to another.   Not
     only  does  the  system  allow  for  more  reliable and
     accurate document transmission over  computer  networks
     but  images  can  also  be  manipulated electronically.
     Image is converted from one  representation  format  to
     another,  so that different makes of facsimile machines
     can communicate with each other.  It is possible for  a
ToP   noToC   RFC0809 - Page 44
     picture to be presented on different  bit-map  devices,
     e.g.  TV-like  screen,  as it can be scaled to overcome
     the incompatibilities.  Moreover, the  system  provides
     windowing   and   overlaying   facilities   whereby   a
     sophisticated editor can be supported.

       One of the most important aspects of this  system  is
     that   text   can  be  converted  into  its  bit-mapped
     representation format  and  integrated  with  pictures.
     Geometric  graphics  could  also  be  included  in  the
     system. Thus, the facsimile  machine  may  serve  as  a
     printer  for  multi-type  documents.  It  is clear that
     facsimile  will  play  an  important  role  in   future
     information processing system.

       As far  as  the  system  per  se  is  concerned,  the
     following  advantages  can  be  recognised.  Though our
     discussion is concentrated  on  the  facsimile  system,
     many  features  developed  here  apply  equally well to
     other information-processing systems.

      (1)  Flexibility:  The  user  jobs   can   be   easily
          organised.  The  only  thing  to  be done for this
          purpose is to  make  the  logical  links  for  the
          appropriate task processes.

      (2) Simplicity: The interface routines are responsible
          for  the  operations  such  as signal handling and
          buffer management.  By avoiding this  burden,  the
          implementation  of the task processes becomes very
          "clean and simple".

      (3) Portability: The interface routines also makes the
          task   processes   totally   independent   of  the
          operating environment.  Only these routines should
          be modified if the environment were changed.

      (4) Ease of extension: The power of the system can  be
          simply  and infinitely extended by adding new task

      (5) Distributed  Environment:  This  approach  can  be
          easily  extended  to  a  distributed  environment,
          where limitless hardware  and  software  resources
          can be provided.

     5.2 Problems

       As discussed earlier, the network we were  using  for
     the  experimental  work was not designed for image data
ToP   noToC   RFC0809 - Page 45
     transmission.  The data transfer  is  so  slow  that  a
     time-out may be caused on the facsimile machine. Though
     this problem was solved by means of local buffering and
     pictures  were successfully exchanged over the network,
     the slowness is rather  disappointing  because  of  the
     quantity of image data. The measurement showed that the
     throughput was around 500 bits/sec. In other words,  it
     took  at  least  5 minutes to transfer a page. This was
     caused by the network but not our system. The situation
     has been improved recently. However, It is nevertheless
     required that more  efficient  compression  schemes  be

       At present, the system must be directly  attached  to
     the  network to be accessed. However, the network ports
     are much demanded, so that frequent reconfiguration  is

       The facsimile system can be  connected  only  to  the
     local  network,  the  Cambridge Ring, while the foreign
     networks are connected via gateways to the  ring.  This
     is shown in Fig. 12. Now the X25 network is attached to
     the Ring via an X25 gateway, XG [25], while  SATNET  is
     connected by another gateway, SG [25]. Both network are
     at the transport level; XG and SG support the  relevant
     transport  procedures.  In  the  case  of  XG,  this is
     NITS/X25 ([26], [27]); in the case  of  SATNET,  it  is
     TCP/IP ([28], [29]).

     UCL facsimile
       system          - - - - - - - -
     +--------+      /                 \      +------+
     !        ! ----    Cambridge Ring   ---- !  PE  !
     +--------+      \                 /      +------+
                       - - - - - - - -            |
                         /         \              |
                   +------+       +------+        |
                   !  XG  !       !  SG  ! --- SATNET
                   +------+       +------+
                   /       \
                 PSS    SERC NET

          Fig. 12  Schematic of UCL network connection

       When the network software runs in the same machine as
     the   application   software,   the  Clean  and  Simple
     interface of section  3.5  was  used  as  an  interface
     between  the  modules.  When  the  gateway software was
     removed to a separate machine, an Inter-Processor Clean
ToP   noToC   RFC0809 - Page 46
     and  Simple  [30]  was   required.    The   appropriate
     transport   process  is  transferred  to  the  relevant
     gateway, and appropriate facilities are implemented for
     addressing   the   relevant   gateway.  Otherwise,  the
     software has to be little  altered  to  cater  for  the
     distributed case.

       In our experimental work, the following problems were
     also encountered.

      (1) The primary memory of the LSI-11 is so small  that
          we  cannot  build  up  a system to include all the
          modules we have developed.  In order  to  transfer
          an  edited picture using the NIFTP module, we have
          to first  load  an  editor  system  to  input  and
          process  the  picture, and then an NIFTP system is
          then loaded to transmit it.

      (2) The execution of  an  image  processing  procedure
          becomes  very  slow. For example, it takes several
          minutes to shrink a picture to fit the  screen  of
          the  Grinnell  display.  This  prevents the system
          from being widely used in its present form.

      (3) As secondary storage, floppy disks  are  far  from
          adequate  to keep image data files. At present, we
          have two double-density floppy  disk  drives,  the
          capacity  of  each  disk  being  about 630K bytes.
          However, an image page contains at least 50K bytes
          and,  sometimes,  this number may be doubled for a
          rather complex picture.  Only a limited number  of
          pages can be stored.

       On the other hand, in our  department,  we  have  two
     PDP11-44s   running  UNIX  together  with  large  disks
     supplying abundant file storage. Their processing speed
     is  much  higher  than  that of the LSIs. The UNIX file
     system  supports   a   very   convenient   information-
     management environment. This inspired the idea that the
     UNIX file system could pretend  to  be  a  file  server
     responsible for storing and managing the image data, so
     that all the processing tasks may  be  carried  out  on
     UNIX. Not only does this immediately solve the problems
     listed above, but the following  additional  advantages
     immediately accrue.

      (1) UNIX provides a  far  better  software-development
          environment than LSI MOS ever can or will.

      (2) The facsimile service can be enhanced to  be  able
ToP   noToC   RFC0809 - Page 47
          to support many users at a time.

      (3) The UNIX file system is so sophisticated that more
          complex data entities can be handled.

       In  fact  the  44s  and  the  LSI-11,  to  which  the
     facsimile  machine  and  Grinnell display are attached,
     are  all  connected  to  the  UCL  Cambridge  Ring.   A
     distributed  processing  environment  can  be  built up
     where a job in one computer can be initiated by another
     and  then the job will be carried out by cooperation of
     both computers.

       In such  a  distributed  system,  the  LSI-11  micro-
     computer,   together   with   the   facsimile  machine,
     constitutes  a   totally   passive   facsimile   server
     controlled  by  a  UNIX  user.  A  page  is read on the
     facsimile machine and the image data stream produced is
     transmitted to the UNIX via the ring. The image data is
     stored  as  a  UNIX  file  and  may  be  processed   if
     necessary.  It  can  also  be  sent via the ring to the
     facsimile server where it  will  be  reprinted  on  the
     facsimile machine.

       In order to build up such a distributed  environment,
     IPCS  [30] is far from adequate for this purpose, as it
     does not provide any facility for a remote  job  to  be
     organised.  In  our  system, the task controller can be
     modified so that the command strings  can  be  supplied
     from  a remote host on the network. Having accepted the
     request, the task  controller  organises  the  relevant
     task  chain and the requested job is executed under its
     control.  The execution  of  the  distributed  job  may
     require  synchronisation  between  the  two  computers.
     These problems are discussed in detail in [31].

       Generally speaking, a distributed system based  on  a
     local network, which supplies cheap, fast, and reliable
     communication, could be the ultimate  solution  of  the
     operational problems discussed in this section. In such
     a system, different system operations are  carried  out
     in the most suitable places.

       For the time being, only a  procedure-oriented  task-
     control  language  is  available  in  this system.  The
     command string of the fitter  can  be  typed  from  the
     system  console  directly,  the corresponding job being
     organised and executed.  Theoretically, this  is  quite
     enough   to  cope  with  any  requirement  of  a  user.
     However,  when  the  job  is  complex,  command  typing
     becomes very tedious and prone to error.
ToP   noToC   RFC0809 - Page 48
       Above the task-controller, a job-controller layer  is
     required  which  provides  a  problem-oriented language
     whereby the user can easily put forward his requirement
     to  the  system.  On receipt of such a command, the job
     controller translates it into a command string  of  the
     task  controller  and  passes  the  string  to the task
     controller so  that  operation  request  can  be  done.
     Sometimes,  one  job  has  to  be  divided into several
     subjobs, which are to be dealt  with  separately.   The
     job  controller  should  be  also  responsible for high
     level calculation and management, so that the user need
     not be concerned with system details.

       In the  system  supporting  facsimile  service  under
     UNIX,  a  set  of high-level command is provided, while
     the command  strings  for  the  facsimile  station  are
     arranged automatically and they are totally hidden from
     a UNIX user.

     5.3 Future Study

       At the next stage, our attention should be moved to a
     higher-level,  more sophisticated system which supports
     a multi-type environment. In such a  system,  not  only
     does   the  facsimile  machine  work  as  an  facsimile
     input/output device, but it should also play  the  role
     of  a  printer  for  the  multi-type  document. This is
     because other data types, e.g. coded character text and
     geometric  graphics  can  be easily converted into bit-
     mapped graphics format which the facsimile  machine  is
     able to accept.

       First of all, a data structure should be designed  to
     represent  multi-type  information.  In  a  distributed
     environment, such a structure should be understood  all
     over  the  system,  so  that multi-media message can be

       In a future  system,  different  services  should  be
     supported,   including  viewdata,  Teletex,  facsimile,
     graphics,  slow-scan  TV  and  speech.  The  techniques
     developed  for facsimile will be generalised for use of
     other bit-mapped image representations, such  as  slow-
     scan TV.

       To improve the performance of the  facsimile  system,
     we  are  investigating  how  we  could use an auxiliary
     special purpose processor to perform some of the  image
     processing   operations.   Such  a  processor  will  be
     essential for the higher data rate  involved  in  slow-
ToP   noToC   RFC0809 - Page 49
     scan TV.
ToP   noToC   RFC0809 - Page 50

      [1] P. T. Kirstein, "The Role of Facsimile in Business
          Communication", INDRA Note 1047, Jan. 1981.

      [2]  T.  Chang,  "A  Proposed  Configuration  of   the
          Facsimile station", INDRA Note 922, May, 1980.

      [3] T.  Chang,  "Data  Structure  and  Procedures  for
          Facsimile Signal Processing", INDRA Note 923, May,

      [4] S. Treadwell,  "On  Distorting  Facsimile  Image",
          INDRA Note No 762, June, 1979.

      [5] M. G. B. Ismail and R.  J.  Clarke,  "A  New  Pre-
          Processing   Techniques   for   Digital  Facsimile
          Transmission", Dept.  of  Electronic  Engineering,
          University of Technology, Loughborough.

      [6]  T.  Chang,  "Mask  Scanning  Algorithm  and   Its
          Application", INDRA Note 924, June, 1980.

      [7] M. Kunt and O. Johnsen, "Block Coding of Graphics:
          A  Tutorial  Review",  Proceedings  of  the  IEEE,
          special issue on  digital  encoding  of  graphics,
          Vol. 68, No 7, July, 1980.

      [8]  T.  Chang,   "Facsimile   Data   Compression   by
          Predictive  Encoding",  INDRA  Note  No  978, May.

      [9] High Level Protocol Group, "A Network  Independent
          File  Transfer  Protocol",  HLP/CP(78)1, alos INWG
          Protocol Note 86, Dec. 1978.

     [10] T. Chang, "The Implementation of NIFTP on LSI-11",
          INDRA Note 1056, Mar. 1981.

     [11] T. Chang, "The  Design  and  Implementation  of  a
          Computerised  Facsimile  System",  INDRA  Note No.
          1184, Apr. 1981.

     [12] T. Chang, "The Facsimile Editor", INDRA Note 1085,
          Apr. 1981.

     [13]  K.  Jackson,  "Facsimile   Compression",  Project
          Report,  Dept.  of  Computer  Science,  UCL, June,
ToP   noToC   RFC0809 - Page 51
     [14] R. Cole and S. Treadwell, "MOS User Guide",  INDRA
          Note 1042, Jan. 1981.

     [15] CCITT,  "Recommendation  T.4,  Standardisation  of
          Group   3   Facsimile   Apparatus   for   Document
          Transmission", Geneva, 1980.

     [16]  "DACOM  6450  Computerfax  Transceiver   Operator
          Instructions", DACOM, Mar. 1977.

     [17] "AED 6200LP Floppy Disk Storage System", Technical
          Manual,  105499-01A,  Advanced Electronics Design,
          Inc. Feb. 1977.

     [18] "The User Manual for Grinnelll Colour Display".

     [19] D. R. Weber,  "An  Adaptive  Run  Length  Encoding
          Algorithm", ICC-75.

     [20] R. Braden and P. L. Higginson, "Clean  and  Simple
          Interface  under  MOS",  INDRA Note No. 1054, Feb.

     [21] L. G. Roberts et al, "The ARPA Computer  Network",
          Computer  Communication  Networks,  Prentice Hall,
          Englewood, pp485-500, 1973.

     [22] I. M. Jacobs et  al:  "General  Purpose  Satellite
          Network",   Proc.   IEEE,   Vol.   66,   No.   11,
          pp1448-1467, 1978.

     [23] J.  W.  Burren  et  al,  "Design  fo  an  SRC/NERC
          Computer   Network",   RL   77-0371A,   Rutherford
          Laboratory, 1977.

     [24] P. T. F.  Kelly,  "Non-Voice  Network  Services  -
          Future     Plans",     Proc.     Conf.    Business
          Telecommunications, Online, pp62-82, 1980.

     [25] P. T. Kirstein, "UK-US  Collaborative  Computing",
          INDRA Note No. 972, Aug. 1980.

     [26] "A Network  Independent  Transport  Service",  PSS
          User   Forum,  Study  Group  3,  British  Telecom,
          London, 1980.

     [27] CCITT, Recommendation X3,  X25,  X28  and  X29  on
          Packet Switched Data Services", Geneva 1978.

     [28]  "DoD  Standard  Transmission  Control  Protocol",
          RFC761,  Information  Sciences  Inst.,  Marina del
ToP   noToC   RFC0809 - Page 52
          Rey, 1979.

     [29]  "DoD   Standard   Internet   Protocol",   RFC760,
          Information Sciences Inst., Marina del Rey, 1979.

     [30] P. L. Higginson, "The Orgainisation of the Current
          IPCS System", INDRA Note No. 1163, Oct. 1981.

     [31] T. Chang, "Distributed Processing for  LSIs  under
          MOS", INDRA Note No. 1199, Jan. 1982.
ToP   noToC   RFC0809 - Page 53
                     Appendix I: Devices
ToP   noToC   RFC0809 - Page 54
AED62(DEV)                                             AED62(DEV)


     aed62 - double density floppy disk


     DCT aed62
     setdct("aed62", 0170, 0170450, 0170450,
             aedini, aedsio, aedint, 0);


     The Double Density disks contain 77 tracks numbered  from  0
     to  76.  There  are 16 sectors (sometimes called blocks) per
     track, for a total of 1232 sectors on each side of the disk.
     These  are  numbered  0  to  1231.  Each sector contains 512
     bytes, for a total of 630,784 bytes  on  each  side  of  the

     Only one side of the floppy can be accessed at a time. There
     is  only one head per drive, and it is located on the under-
     side of the disk. To access the other side, the disk must be
     manually removed and inserted the other way up.

     Each block is actually two blocks on the disk:  an  adddress
     ID  block  and the data block.  The address ID block is used
     by the hardware and contains the  track  number,  the  block
     number and the size of the data block that follows.  When an
     operation is to take place, the seek mechanism first locates
     the  block  by  reading  the address ID blocks and literally
     'hunting' for the correct one. It will  hunt  for  up  to  2
     seconds before reporting a failure.

     Both the address ID and the data blocks are  followed  by  a
     checksum word that is maintained by the hardware and is hid-
     den from the user. On writing, the  checksum  is  calculated
     and  appended  to the block. On reading it is verified (both
     on reading the ID and data blocks) and any error is reported
     as  a  Data Check. No checking on the data block takes place
     on a write, and the hardware has no idea if it  was  written
     correctly. The only way to verify it is to read it.

     Although there are two drives in the unit,  they  cannot  be
     used  simultaneously. If an operation is in progress on one,
     no access can be made to the other until the first operation
     is  complete. The driver will queue requests for both drives
     however, and ensure that are performed in order.

     The MOS driver is called aed62.obj. It operates on the  fol-
     lowing IORB entries:
ToP   noToC   RFC0809 - Page 55

          The operation to be performed, as follows:

                          0 - Read
                          1 - Write
                          2 - Verify
                          3 - Seek

          Read and Write cause data to be transferred to and from
          disk.  Verify does a hardware read without transferring
          the data to memory and is used for verifying  that  the
          data  can be successfully read. The checksum at the end
          of  the  block  of  each  sector  is  verified  by  the
          hardware.  The  seek  command  is used to move the disk
          heads to a specified track.


          The drive number. Only Zero or One is accepted. This is
          matched  against the number dialed on the drive. If the
          number is specified  on  both  drives,  or  neither,  a
          hardware error will be reported.


          The Sector or Block Number. Must be in the range  0  to
          1231 inclusive.  irusr2 specifies the block number that
          the transfer is to begin at for Read and Write, the be-
          ginning  of  the  verified area for the Verify command,
          and the position of the head for the Seek  command.  In
          the  latter  case  the  head  will be positioned to the
          track that contains the block.


          This specifies the data  adress,  which  must  be  even
          (word  boundary).   If an odd address is given, the low
          order bit is set to zero to make it even. Not  required
          for the Seek or Verify commands.


          Transfer length as a positive number of bytes. Not  re-
          quired for the seek command, bit IS used by Verify com-
          mand so that the correct number of blocks may be  veri-
          fied.  The disk is only capable of transferring an even
          number of bytes. If an odd length is given the low ord-
          er  bit  is made zero to reduce the length to the lower
          even value.  The length is NOT restricted to the sector
          size  of  512 bytes. If the length is greater than 512,
          successive blocks are read/written until  the  required
ToP   noToC   RFC0809 - Page 56
          length has been satisfied. If the length is not an  ex-
          act  multiple  of  512 bytes, only the specified length
          will be read/written. Note  that  the  hardware  always
          reads  and  writes  a  complete sector, so specifying a
          shorter length on a read will cause  the  remainder  of
          the  block to be skipped. On a write, the hardware will
          repeat the last specified  word  until  the  sector  is

     The driver will attempt to recover  from  all  soft  errors.
     There  is no automatic write/read verify as on mag tapes, so
     that data that is incorrectly written will not  be  detected
     as such until a read is attempted. For this reason, the ver-
     ify feature can be used (see above) to force the checking of
     written  data.  When an error is detected while performing a
     read, the offending block will be re-read up to 16 times and
     disk  resets  will be attempted during this time too. If all
     fails a hardware error indication is returned to  the  user.
     Other errors possible are Protection Error (attempt to write
     to a read-only disk) and User Error,  which  indicates  that
     the  parameters  in  the IORB were incorrect. Errors such as
     there being no disk loaded, or the drive door being open are
     NOT  detectable  by the program. The interface sees these as
     Seek Errors (i.e. soft errors), and thus the driver will re-
     try  several times before returning a Hardware Error indica-
     tion to the user. It should be noted that error recovery can
     take  a  long  time. As mentioned above, there is a 2 second
     delay before a seek error is reported by the  hardware,  for
ToP   noToC   RFC0809 - Page 57
GRINNELL(DEV)                                       GRINNELL(DEV)


     grinnell - colour display


     DCT grndout
     setdct("grndout", 03000, 0172520, 0172522,
             grnoi, grnot, grnoti, &grndin);
     DCT grndin
     setdct("grndin", 03000, 0172524, 0172526,
             grnoi, grnot, grnoti, &grndout);


     The Grinnell colour display has a screen  of  512x512  pels.
     Three colours (red, green and blue) can be used, but no grey
     scale is supported.  Three  graphics  modes  are  available.
     These are:

      (1) Alphanumeric: The input ASCII characters are  displayed
          at the selected positions on the screen.

      (2) Graphic: Basic geometric elements,  such  as  line  and
          rectangle, are drawn by means of graphics commands.

      (3) Image: The input data is interpreted as  bit  patterns,
          the corresponding images being illustrated.

     The values used to construct commands are described  in  the
     Grinnell User Manual. They are also listed below.

      #define LDC     0100000   /* Load Display Channels */

      #define LSM     0010000   /* Load Subchannel Mask */
      #define   RED   0000010   /* Read Subchannel */
      #define   GREEN 0000020   /* Green subchannel */
      #define   BLUE  0000040   /* Blue subchannel */

      #define WID     0000000   /* Write Image Data */
      #define WGD     0020000   /* Write Graphic Data */
      #define WAC     0022000   /* Write AlphanumCh */

      #define LWM     0024000   /* Load Write Mode */
      #define   REVERSE  0200   /* Reverse Background */
      #define   ADDITIVE 0100   /* Additive (not Replace) */
      #define   ZEROWRITE 040   /* Dark Write */
      #define   VECTOR    020   /* Select Vector Graph */
      #define   DBLEHITE  010   /* Double Height write */
      #define   DBLEWIDTH 004   /* Double Width write */
      #define   CURSORAB  002   /* Cursor (La+Lb,Ea+Eb) */
ToP   noToC   RFC0809 - Page 58
      #define   CURSORON  001   /* Cursor On */

      #define LUM     0026000   /* Load Update Mode */
      #define   Ec        001   /* Load Ea with Ec */
      #define   Ea_Eb     002   /* Load Ea with Ea + Eb */
      #define   Ea_Ec     003   /* load Ea with Ea + Ec */
      #define   Lc        004   /* Load La with Lc */
      #define   La_Lb     010   /* Load La with La + Lb */
      #define   La_Lc     014   /* Load La with La + Lc */
      #define   SRCL_HOME 020   /* Scroll dsiplay to HOME */
      #define   SRCL_DOWN 040   /* Scroll down one line */
      #define   SCRL_UP   060   /* Scroll up one line */

      #define ERS     0030000   /* Erase */
      #define ERL     0032000   /* Erase Line */
      #define SLU     0034000   /* Special Location Update */
      #define   SCRL_ZAP 0100   /* unlimited scroll speed */

      #define EGW     0036000   /* Execute Graphic Write */
      #define LER     0040000   /* Load Ea relative */
      #define LEA     0044000   /* Load Ea */
      #define LEB     0050000   /* Load Eb */
      #define LEC     0054000   /* Load Ec */
      #define LLR     0060000   /* Load La Relative */
      #define LLA     0064000   /* Load La */
      #define LLB     0070000   /* Load Lb */
      #define LLC     0074000   /* Load Lc */
      #define   LGW     02000   /* perform write */

      #define NOP     0110000   /* No-Operation */

      #define SPD     0120000   /* Select Special Device */
      #define LPA     0130000   /* Load Peripheral Address */
      #define LPR     0140000   /* Load Peripheral Register */
      #define LPD     0150000   /* Load Peripheral Data */
      #define RPD     0160000   /* ReadBack Peripheral Data */
      #define MEMRB     00400   /* SPD - Memory Read-Back */
      #define DATA      01000   /* SPD - Byte Unpacking */
      #define   ALPHA   06000   /* LPR - Alphanumeric data */
      #define   GRAPH   04000   /* LPR - Graphic data */
      #define   IMAGE   02000   /* LPR - Image data */
      #define   LTHENH  01000   /* take lo byte then hi byte */
      #define   DROPBYTE 0400   /* drop last byte */
      #define INTERR    02000   /* SPD - Interrupt Enable */
      #define TEST      04000   /* SPD - Diagnostic Test */

     The MOS driver is called grin.obj. It operates on  the  fol-
     lowing IORB entries.


          This is a pointer to  the  buffer  where  the  data  is
ToP   noToC   RFC0809 - Page 59
          This data must be ready formtatted  for  the  Grinnell,
          since no conversion is performed by the driver.


          This transfer length as a positive number of bytes.

     Addressing the grinnell. Rows consist of elments numbered  0
     to 511 running left to right. The lines are number from 0 to
     511 running from bottom to top. It is thus  addressed  as  a
     conventional  X-Y  coordinate system. Note that this coordi-
   e system is different the one used for the image.

        X A
          |                                 (511, 511)
      511 +-------------------------------+
          |                               |
          |                               |
          |                               |
          |                               |
          |             (x, y)            |
          |            +                  |
          |                               |
          |                               |
          |                               |
          |                               |
          |                               |
         0                               511    Y