description

ftam等标准协议服务器和客户端的源代码。

_1.  _O_v_e_r_v_i_e_w _o_f _p_e_p_s_y _s_y_s_t_e_m

     This  section  describes  how  the  various  parts  fit
together  to  make  the  system  work.  The principle behind
pepsy is fairly simple.  The ASN.1 is summarised  as  tables
of integers.  These tables are read by driver routines which
encode or decode data to or from the  internal  format  that
ISODE  OSI implementation uses.  In ISODE specific functions
are generated for each ASN.1 type defined  in  contrast  the
pepsy  merely generates a new table of data which is far far
smaller.

     As there is a great deal  of  effort  invested  in  the
ISODE  interface  to  the  encoding/decoding  routines pepsy
automatically provides macros which map the  original  func-
tions  into the appropriate function call of a driver.  This
allows existing posy using code to switch to the pepsy  sys-
tem  with  no  changes  to  the  code  provided  no function
pointers are used to the  original  ISODE  functions.   Even
when  there  are function pointers used the changes are very
simple and take only a few hours to implement.

_1._1.  _B_r_i_e_f _d_e_s_c_r_i_p_t_i_o_n _o_f _t_h_e _u_s_e _o_f _t_h_e _p_e_p_s_y _s_y_s_t_e_m.

_1._1._1.  _O_u_t_l_i_n_e _o_f _t_h_e _f_i_l_e_s _p_r_o_d_u_c_e_d _u_n_d_e_r _t_h_e  _p_e_p_s_y  _s_y_s_-
_t_e_m.

     The pepsy system consists  of  a  program  called  _p_o_s_y
which  translates ASN.1 modules into a set of tables, called
_p_o_s_y at the moment, and library of driver  routines,  called
_l_i_b_p_e_p_s_y._a.   Running  this  _p_o_s_y  program on the ASN.1 file
will produce several files.  If the name of the ASN.1 module
is MODULE the following files are generated:

MODULE-types.h
     which contains C structure definitions.   The  user  of
     the  library  provides data as a linked list of these C
     data structures and expects to receive data back  as  a
     similar linked list.  These data structures are exactly
     the same as those produced by the original  ISODE  _p_o_s_y
     so that existing software written for the old _p_o_s_y pro-
     gram needs no change.  For details on the C data struc-
     tures types generated see the documentation of the ori-
     ginal _p_o_s_y program in volume 4 Chapter 5 of  the  ISODE
     manuals.

MODULE_tables.c
     This file contains the tables generated by the new _p_o_s_y
     program.   These  tables  consist  of  three parts, the
     first which contains the summary of ASN.1 types.   Each
     type  is  summarised  as  an array of a primitive type,
     struct pte, for encoding and decoding, and struct  ptpe
     for  printing.   As implied there is one array for each
     type for each of encoding,  decoding  and  printing  as



                      January 23, 1990





                           - 2 -


     specified  when _p_o_s_y is run.  The next part contains up
     to three tables of pointers to these arrays.   Each  of
     the three different types of arrays, encoding, decoding
     and printing, has its own table of  pointers.   Finally
     there is the module type definition which contains con-
     tains pointers to these tables and  some  other  useful
     information  about  the  module such as its name.  This
     module type structure, which is typedefed to modtyp, is
     the only piece of data which is global, all the rest of
     the data is static and is only addressable via the mod-
     typ  data  structure.  This  provides  a kind of object
     oriented approach to handling the tables.  Once you are
     passed a pointer to an ASN.1's modtyp structure you can
     encode, decode and print any of its  types  by  calling
     the   appropriate  libpepsy.a  routine  with  its  type
     number.

MODULE_pre_defs.h
     This file contains #defines symbol of each of the ASN.1
     types  to its type number, which is used when calling a
     libpepsy.a routine.  Each symbol  is  _Ztype-nameMODULE
     where _t_y_p_e-_n_a_m_e is the name of the type with dashes (-)
     turned into underscores (_) and _M_O_D_U_L_E is the  name  of
     the  module.   For  example of the ASN.1 universal type
     _G_r_a_p_h_i_c_S_t_r_i_n_g would  have  the  #define  symbol  _ZGra-
     phicStringUNIV.  The __Z is prepended to try to make the
     symbols unique.  This file  also  contains  and  extern
     declaration for the modtyp data for its module.

MODULE_defs.h
     This file contains macros for  all the encoding, decod-
     ing  and printing functions that the _p_e_p_y program would
     have for these ASN.1 types.  This allows  much  of  the
     code  that  uses  the routines generated by running the
     old _p_o_s_y program and taking its output and running _p_e_p_y
     on  augmented ASN.1 output can be recompiled unchanged.
     If the code used pointers  to  these  functions  it  is
     necessary  to change it to pass around the type numbers
     instead and to call  appropriately  call  a  libpepsy.a
     library  routine  with the type number.  As pointers to
     the printing routines in ISODE are passed as  arguments
     a  #define  is  provided  to turn the argument into the
     pair of arguments, type number and  pointer  to  modtyp
     structure,  which  are  needed  to allow the diagnostic
     printing code to work with no change  for  the  current
     ISODE stack.  This file also contains a #include of the
     _M_O_D_U_L_E__p_r_e__d_e_f_s._h file.

     As the _M_O_D_U_L_E-_t_y_p_e_s._h file #include's the _M_O_D_U_L_E__d_e_f_s._h
file  no  further  #includes  need  to be added to the files
using the encoding/decoding/printing functions.  This  means
that code written to use posy/pepy system may need no change
at all and  the  only  effort  required  is  to  change  the
Makefile  to use the pepsy system.  If there is code changes



                      January 23, 1990





                           - 3 -


required it would most likely be because  function  pointers
are  used  to reference the functions generated by posy.  If
only the _p_e_p_y system was used, not posy then pepy, with code
placed inside action statements then quite a large amount of
work may be needed to change over to the new system, depend-
ing on how large and complex the _p_e_p_y module is.

_1._1._2.  _O_u_t_l_i_n_e _o_f _t_h_e _p_e_p_s_y _l_i_b_r_a_r_y.

enc.cThis contains the routines that encode data from the  C
     data  structures into ISODE's PElement linked list data
     structure which it uses for all presentation data.  The
     most  important  function to pepsy users is enc_f which
     called to encode a particular type.  It is  passed  the
     type  number and a pointer to modtyp structure for that
     module and then the rest of  the  arguments  which  are
     passed  to  an  encode  function generated by _p_o_s_y/_p_e_p_y
     system.  See the documentation in Volume 4, "The Appli-
     cations  Cookbook",  Section  6.4 called "Pepy Environ-
     ment".  Most of these  latter  arguments  are  ignored,
     only parm and pe, are used.

     Contrary to what the  ISODE  documentation  says  these
ignored  parameters  are  hardly ever used by existing code.
We have not found a single case where used  for  encoding  a
named type, which is all that the user can reference anyway,
so we don't see  any  problems  with  ignoring  these  other
parameters.   Hopefully  one  day  they  can  be thrown away
entirely, until then they are actually passed the the encod-
ing function.

     The rest of the functions are mostly recursive routines
which  encode a particular type of table entry.  For example
SEQUENCE is encoded by en_seq which may call itself or  oth-
ers  to  encode  the  types  from which it is built up.  The
function en_type builds up a simple type and en_obj  encodes
a  new  type (object) and so on with other functions.  There
are a few utility routines in the file such  as  same  which
determines  whether  the  value  is  the same as the default
value also.

dec.cThis file contains the decoding routines that translate
     presentation data into C data structures defined in the
     MODULE-types.h is like _e_n_c._c.  It is very much like the
     file _e_n_c._c except the routines do the reverse tasks The
     routines are structured in a very similar way.  We have
     dec_f  which is called by the user to decode a type and
     like enc_f takes the same  arguments  as  the  decoding
     functions  generated  by  _p_o_s_y  with two additions, the
     type number and a pointer to the modtyp  structure  for
     that  module.   Likewise  the  other functions are very
     much like those of enc.c

prnt.cThis  file  contains  the  routines  that  print   the



                      January 23, 1990





                           - 4 -


     presentation data in a format similar to that generated
     by  _p_e_p_y's  printing  functions.   It's  main  function
     prnt_f  is  takes  the  same  arguments as the printing
     function generated by _p_e_p_y as well as the now  familiar
     type  number  and  modtyp  pointer.   The functions are
     modeled on the decoding routines as it has similar  job
     to.  The only difference is that instead of storing the
     decoded data into a  C  data  structure  it  is  nicely
     printed out.

fr.c This file contains code to  free  the  data  structures
     defined  in MODULE-types.h.  Likewise if the -f flag is
     given when generating the types file it  also  includes
     macros  in  the  types  file  which replace the freeing
     functions generated by ISODE's _p_o_s_y.  The function that
     the  user calls us fre_obj which takes a pointer to the
     data structure, its decoding table entry and a  pointer
     to  the modtyp structure for the module. The freeing is
     based on the decoding routines except instead of decod-
     ing  all  it  does is free each part of the data struc-
     ture, which might  involve  recursive  calls,  then  it
     frees the data structure at the end.

util.cThis contains the utility routines used by  more  than
     one of the above files.  This is mostly diagnostic rou-
     tines at the moment, more  general  routines  could  be
     included  in  here.  If there is an error at the moment
     which it can't recover from it just prints out  a  mes-
     sage on standard error and calls exit.  Not perfect and
     this is something that will need work.

main.cThis contains code to perform a series of tests on the
     _p_e_p_s_y  library  which  is a useful check to see whether
     any of the routines has  been  broken  by  any  changes
     made.   It  basically  loops  through a whole series of
     test cases.  Each test case is encoded from some  built
     in test data and then decoded and checked to see if the
     data has changed in the transfer.  If  it  is  compiled
     with  -_D_P_R_N_T=_1  the encoded data is also printed out to
     check the printing  routines  which  generates  a  vast
     amount  of  output.  Finally the free routines are used
     to  free  the  allocated  data,  although  it  can  not
     directly  check  the free routines to see if they work,
     it can be used with a malloc tracing package  to  check
     that the routines work.

test_table.h
     This contains the test cases that _m_a_i_n._c program  runs.
     Each  entry in the table corresponds to a type.  One of
     the fields is count of how many times that type  is  to
     be tested to try out the different possibly data values
     it might have.

pep.h and pepdefs.h



                      January 23, 1990





                           - 5 -


     These files contain the definition of  types  used  for
     the  tables  that  drive the encoding/decoding/printing
     routines.  All the constants used  in  that  table  are
     defined  here  via  #defines.   The modtyp structure is
     defined in _p_e_p_d_e_f_s._h.

t1.py and t2.py
     These are test ASN.1 modules that are  used  by  _m_a_i_n._c
     routines  to  check  the _p_e_p_s_y library.  The file _t_1._p_y
     contains the majority of different types with a few  of
     a  different module provided in _t_2._p_y.  This allows the
     testing of the code for handling ASN.1 external  refer-
     ences,  i.e.  references  to  types  defined  in other,
     external, modules.

_1._1._3.  _N_e_w _f_i_l_e_s _i_n _t_h_e _p_e_p_y _d_i_r_e_c_t_o_r_y

etabs.c, dtabs.c and ptabs.c
     These  files  contain  the   code   to   generate   the
     encoding/decoding/printing tables.  The main routine in
     _e_t_a_b_s._c is tenc_typ which is called on each ASN.1  type
     to  generate  an array of entries which describe how to
     encode that type.  See the  details  section  for  more
     information  about  how  the  table  entries  function.
     Similarly _d_t_a_b_s._c contains the routine  tdec_typ  which
     is  called  on each type to generate its decoding table
     entries.   Likewise  tprnt_typ  routine  generates  the
     arrays  of table entries for the printing tables.  This
     function is in _p_t_a_b_s._c.

dfns.cThis file contains miscellaneous string handling  rou-
     tines  and hash table routines that don't really belong
     anywhere else.  Some of the routines could  be  cleaned
     up in that they tend not to free memory they use.

mine.hThis  file  contains  the  definitions  for  the  hash
     table(s)  that  are  used  to  keep  track of the ASN.1
     types.  This could probably be done  with  out  a  hash
     table,  should  anyone want to clean this up, feel wel-
     come.  The lookup function is in _d_f_n_s._c.

pass2.h
     This file has most of the #defines for the  table  gen-
     erating  program.  Most of the prefixes and suffixes of
     function names and files names  are  defined  here  so,
     hopefully,  the names can be changed by merely changing
     the definition.  This contains most  of  the  important
     definitions  needed  by the changes to the _p_o_s_y program
     needed to generate tables.

posy.hThis contains the definition of a symbol which is  now
     needed  outside  of  the  the main routine and the yacc
     file.  By putting it here we can include  it  any  file
     that  needs  to  know  it  with out putting in any that



                      January 23, 1990





                           - 6 -


     doesn't need it and with out including  all  the  other
     definitions  that  occur  in _p_e_p_y._h.  The structure and
     meaning of the tables generated from the ASN.1 grammar

     Each collection of ASN.1 grammar is  called  a  module.
(See  ASN.1  )  Each ASN.1 module is completely specified in
the program by a single C structure of type modtyp  and  the
data  which  it  references.   See the _p_e_p_d_e_f_s._h file in the
_p_e_p_s_y directory.  For each  ASN.1  module  there  are  three
tables that are generated fromASN.1 grammar.  These initial-
ised arrays which we call tables are  called  the  encoding,
decoding  and  printing  tables.   Each  of  these tables is
referenced through a different pointer of the modtyp  struc-
ture.

     Each of these pointers references an array of pointers,
one  pointer for each ASN.1 type defined in the module.  The