rfc809.txt

RFC 相关的技术文档

     facsimile  format,  the  system maintains a translation
     table whereby the patterns of the characters  available
     in  the  system  can  be retrieved. The input character
     string is translated into a set of scan lines, each  of
     which  is  created  by  concatenating the corresponding
     patterns of the characters in the string.

       The translation table is in  fact  a  software  font,
     which  can be edited and modified. Even though only one
     font is available in our system for the time being,  it
     is  quite  easy  to  introduce  other  character fonts.
     Furthermore, it is also  possible  for  a  font  to  be
     remotely  loaded  from a database via the communication
     network.





                             - 16 -

UCL FACSIMILE SYSTEM                              INDRA Note 1185

       This allows for more interesting applications of  the
     facsimile  machine.  For  example,  it could serve as a
     Teletex printer, provided that  the  Teletex  character
     font  is included in our system. In this case, the text
     images may be distorted to fit the presentation  format
     requested  by  the Teletex service.  Similarly, Prestel
     viewdata pages  could  be  displayed  on  the  Grinnell
     screen.

       Moreover,  pictures  can  be  mixed  with   text   by
     combining   this   text  conversion  with  the  editing
     described in  the  previous  section.  This  should  be
     regarded   as   a   notable   step  towards  multi-type
     processing.

       Not  only  does  this  support  a  local   multi-type
     environment   but   multi-type   information   can   be
     transmitted over a network. So far  as  this  facsimile
     system  is  concerned, a mixed page containing text and
     pictures can be sent only when it has been  represented
     in  a  bit-map  format.  However,  much  more efficient
     transmission would be achieved if  one  could  transmit
     the text and pictures separately and reproduce the page
     at the destination site. This requires  that  a  multi-
     type  data structure be designed which is understood by
     the two communication sites.


     3. SYSTEM ARCHITECTURE

       Now let us discuss the general disciplines for design
     and  implementation  of a computerised facsimile system
     which  carries  out  the  functions  described  in  the
     previous  sections.   Having discussed the requirements
     of the system, a hierarchical model  is  introduced  in
     which  the  modules of different layers are implemented
     as separate processes.  The Clean and Simple interface,
     which  is  adopted  for inter-process communication, is
     then  described.   The  task   controller,   which   is
     responsible  for  organising  the  tasks  involved in a
     requested job, is discussed in  detail.   Some  efforts
     have  been  made  in our experimental work to provide a
     more convenient user programming environment and a more
     efficient   data   transfer  method.  This  is  finally
     described.


     3.1 System Requirements

       In a computerised facsimile system,  the  images  are
     represented  in  a  digital  form.  To  carry  out this




                             - 17 -

UCL FACSIMILE SYSTEM                              INDRA Note 1185

     conversion, a page is scanned by the optical scanner of
     the  facsimile machine, a digital number being produced
     to represent  the  darkness  of  each  pixel.  As  high
     resolution  has to be adopted to keep the detail of the
     image, the facsimile  data  files  are  usually  rather
     large.  In  order  to  achieve  efficient  storage  and
     transmission, the facsimile data must be compressed  as
     much as possible.

       Currently, the facsimile machines made  by  different
     manufacturers   h different  properties,  such  as
     different compression methods and different resolution.
     There   are   also  some  international  standards  for
     facsimile data compression, which are employed for  the
     facsimile  data  to be transferred over the public data
     network. These  require  that  the  facsimile  data  be
     converted  from  one representation form to another, so
     that users who are  separated  geographically  and  use
     different  machines  can  communicate  with each other.
     More sophisticated applications,  e.g.  image  editing,
     request processing facilities of the system as well.

       When being processed, the facsimile image  should  be
     represented   in  a  common  format  or  internal  data
     structure,  which  is  used  to  pass  the  information
     between  different processing routines. For the sake of
     convenience and efficiency, the internal data structure
     should  be fairly well compressed and its format should
     be  easy  for  the  computer  to  manipulate.  In   our
     experimental  work,  the  line  vector  is  chosen as a
     standard unit, a simple  run-length  compression  being
     employed  [3].  Some  processing routines may use other
     data   formats,   e.g.   bit-map,   but   it   is   the
     responsibility   of   such   routines  to  perform  the
     conversion between those formats and the standard one.

       The  system   should   contain   several   processing
     routines,  each  of  which performs one primitive task,
     such  as  chopping,  merging,  and  scale-changing.  An
     immense variety of processing operations can be carried
     out as long as those  task  modules  can  be  organised
     flexibly. The capability for flexible task organisation
     should be thought of  as  one  of  the  most  important
     requirements of the system.

       One  possibility  is  for  the  processing   routines
     involved  to  be  executed  separately, temporary files
     being used as communication media. Though very  simple,
     this method is far too inefficient.






                             - 18 -

UCL FACSIMILE SYSTEM                              INDRA Note 1185

       As described above,  the  information  unit  for  the
     communication  between  the  processing routines is the
     line vector, so that the routines can be  organised  as
     embedded  loops,  where  a processing routine takes the
     input line from its source routine located in the inner
     loop,  and  passes  the  output line to the destination
     routine located in the outer loop [3].  Obviously  this
     method  is quite efficient. But it is not realistic for
     our system, because it is very difficult  to  build  up
     different  processing  loops  at  run-time and flexible
     task organisation is impossible.

       In a  real-time  operating  system  environment,  the
     primitive   tasks   can   be  implemented  as  separate
     processes. This method, which is discussed in detail in
     the   following   sections,   provides   the   required
     flexibility.


     3.2 Hierarchical Model

       As shown in Fig. 7, the modules in a single  computer
     fall into three layers.


                       +---------+
                       !         ! task controller
                       +---------+

                              tasks
                +---+  +---+  +---+  +---+  +---+
                !   !  ! !   !  !   !  !   !
                +---+  +---+  +---+  +---+  +---+
                  |      |                    |
                +---+  +---+                +---+
                !   !  !   ! device drivers !   !
                +---+  +---+                +---+
            - - - | - -  |  - - - - - - - - - | - - - -
                +---+  +---+                +---+
                !   !  !   !    physical    |   !
                !   !  !   !    devices     !   !
                +---+  +---+                +---+

                 Fig. 7  The hierarchical model


       These are:

      (1) Device Drivers, which constitute the lowest  layer
          in the model.  The modules in this layer deal with
          I/O activities of the physical  devices,  such  as




                             - 19 -

UCL FACSIMILE SYSTEM                              INDRA Note 1185

          facsimile machine, display and floppy  disk.  This
          layer  frees  the task modules of upper layer from
          the burden of I/O programming.

      (2) Tasks, which perform all processing primitives and
          handle different data structures. Above the driver
          of each physical device, there  are  one  or  more
          such  device-independent  modules,  which  work as
          information source or sink in the task chain  (see
          below).  A file system module allows other modules
          to store and retrieve information on the secondary
          storage  device such as floppy disk. Decompression
          and recompression routines convert data structures
          of   facsimile   image  information  so  that  the
          facsimile machines can communicate with  the  rest
          of   the   system.   Processing  primitives,  e.g.
          chopping, merging,  scaling,  are  implemented  as
          task modules in this layer. They are designed such
          that they can be concatenated to  carry  out  more
          complex  jobs.  So far as the system is concerned,
          the protocols for data transmission over  computer
          networks are also regarded as task modules in this
          layer.

      (3)  Task  Controller,  which   organises   the   task
          processes   to   perform  the  specified  job.  It
          provides the users of the application layer with a
          procedure-oriented  language whereby the requested
          job can be defined as a  chain  of  task  modules.
          Literally, the chain is represented by a character
          string:


             <source_task>|{<processing_task>|}<sink_task>


            According to such a command, the task controller
          selects the relevant task modules and concatenates
          them in proper order by means  of  logical  links.
          Then the tasks on the chain are executed under its
          control, so that the data taken  from  the  source
          are processed and the result is put into the sink.


     3.3 Clean and Simple Interface

       It is important, in this application, to develop  the
     software  in  a  modular  way.  It  is desirable to put
     together a set of modules to carry  out  the  different
     image   processing  tasks.  Another  set  of  transport
     modules must be developed for shipping  data  over  the




                             - 20 -

UCL FACSIMILE SYSTEM                              INDRA Note 1185

     different networks to which the UCL system is attached.
     In   our  computerised  facsimile  system,  these  task
     modules are  implemented  as  separate  processes.  The
     operation  of  the  system  relies on the communication
     between these processes.  The interface which  is  used
     for   such   communication  has  been  designed  to  be
     universal; it is independent of these modules, and  has
     been  termed  the Clean and Simple interface [20]. This
     interface is discussed in this section.


     3.3.1 Principles

       The Clean and Simple interface is concerned with  the
     synchronisation   and   transfer  of  full-duplex  data
     streams between two communicating processes.  Thus  the
     interface   has   three  major  components:  connection
     synchronisation,   data   transfer    and    connection
     desynchronisation.   These   components  are  discussed
     below.

       The connection between two processes is initiated  by
     one  of  them,  which, generally speaking, belongs to a
     higher  layer.  For  example,  the  interface   between
     protocols  of  different  layers is always initiated by
     the higher layer, though, sometimes, the connection  is
     initiated  passively by the primitive 'listen'. It will
     be seen in the next section  that  task  processes  can
     communicate  with each other via the connections to the
     higher  layer  (task  controller)  and  this  makes  it
     possible to achieve flexible task organisation.

       The process initiating the connection is  called  the
     'master' process, while the other is called the 'slave'
     process. The 'master' process is also  responsible  for
     resource   allocation   for   the   two   communicating
     processes. Here 'resource' refers mainly to the  memory
     areas  for  the message structure and data buffer. This
     asymmetric definition of the interface  eliminates  any
     possible confusion in resource allocation.

       The interface is implemented by using the signal-wait
     mechanism  provided  by  the  operating  system. A data
     structure called CSB (Clean and  Simple  Block),  which
     contains  function, data buffer, and other information,
     is sent as the event message, when one process  signals
     another [20].








                             - 21 -

UCL FACSIMILE SYSTEM                              INDRA Note 1185

     3.3.2 Synchronisation and Desynchronisation

       The  procedure  for  connection  synchronisation   is
     composed   of  two  steps.  First,  the  two  processes
     exchange their identifiers for the specific  connection
     by  means  of a getcid primitive.  Usually, the pointer
     to the task control structure of the process is used as
     the connection identifier.

       Then, the 'master' sends an open CSB with appropriate
     parameter    string    passing    the    initialisation
     information. This information, which can also be called
     open   parameter,   is   process   dependent,  or  more
     accurately, task dependent. For example, the parameters
     for  the  file  system  should be the file name and the
     access mode. Provided the 'slave' accepts the  request,
     the connection is established successfully and data can
     be transferred via the interface.

       In  order  to  desynchronise  the   connection,   the
     'master' initiates a 'close' action. On the other hand,
     an error state or  EOF  (end  of  file)  state  can  be
     reported   by  the  'slave'  to  request  a  connection
     desynchronisation.

       The listen primitive in our system  is  reserved  for
     the  processes  that  receive a request from the remote
     hosts on the networks.


     3.3.3 Data Transfer

       While the Clean and Simple interface is asymmetric in
     relation  to  connection synchronisation, data transfer
     is completely symmetric so long as the  connection  has