description

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

     entry  type  formed  by removing the starting `S'.  The
     above forms would do to handle ASN.1 but we  also  have
     to  be  compatible with the C data structures generated
     by _p_o_s_y.  The implementors decided to  optimise  the  C
     data  structures  generated  a  little means we have to
     have all these S type entries.  If a type was a  single
     field in most cases they produced a #define which elim-
     inates the need to have a whole structure just for that
     type.   In  all  the places where this type is used the
     field of the C structure is changed from a  pointer  to
     field  which holds the value directly in the structure.
     See the ISODE reference given above for more details.

     We handle this by generating the same tables that would



                      January 23, 1990





                           - 12 -


be generated with out the optimisation, except the optimised
types the S-type of entries instead of the normal ones.  For
example  an optimised OCTET STRING would have the type field
of its entry as SOCTETSTRING instead  of  OCTETSTRING.   The
only  difference  in how S type and its corresponding normal
are handle is how they find the C data  structure  for  that
entry.   That  difference  is  that  there is no indirection
through pointers.

Flags field
     Besides the encoding the class the pe_flags field  also
     contains  a  few  possible  flags.   Mainly FL_OPTIONAL
     which means the ASN.1 type corresponding to  this  flag
     is  OPTIONAL.   Consequently  when  encoding  it has to
     determine if the type is present in the user data  pos-
     sibly  using  the  bit  map as described under the OPTL
     entry.  Likewise when decoding it may have to set a bit
     in  the  bit  map appropriately.  The other flag at the
     moment is FL_DEFAULT which means the entry  corresponds
     to  an ASN.1 DEFAULT type.  This bit is still needed as
     not all types have DFLT_* entries implmented  for  them
     at  the  moment.   In  particular compound value things
     like SEQUENCE and SET can't have  thier  default  value
     specified.   This  is  consistent  with  ISODE, if fact
     implementing that may even break existing  ISODE  code.
     This last flag FL_IMPLICIT is obsolete and not not used
     any where.


_1._2.  _W_a_l_k _t_h_r_o_u_g_h _o_f _p_e_p_s_y _l_i_b_r_a_r_y _r_o_u_t_i_n_e_s.

     Here we walk through all the pepsy library routines  at
least  briefly.   If any new routines are added or a routine
changed this documentation is the most likely part that will
need changing.  First we give some theory as to how the task
have have been brocken  into  routines  then  describe  each
function in detail.  We assume you are familiar with ISODE's
PE data structure manipulation routines.  if  not  they  are
documented  in  the  ISODE  manuals,  Volume one, chapter 5,
"Encoding of Data-Structures" (It actually  covers  decoding
as well).

_1._2._1.  _O_v_e_r_v_i_e_w _o_f _p_e_p_s_y _l_i_b_r_a_r_y

     Each seperate task is put into a  different  file.   So
all  the  encoding stuff is in _e_n_c._c, all the decoding stuff
is in _d_e_c._c, printing stuff in _p_r_n_t._c and freeing  stuff  in
_f_r_e._c.   Actually  it breaks down a little in practice, some
of the routines for moving around the  tables  are  used  in
both  _e_n_c._c  and  _d_e_c._c  for  example.  Probably they should
defined in _u_t_i_l._c so that linking one of the files from  the
library doesn't force linking any other except _u_t_i_l._o.

     There is a common structure to each of the major  files



                      January 23, 1990





                           - 13 -


as  well.   There  is a main routine which the user calls to
obtain the services provided by that  file's  routines.   As
all  the  files  revolve  about processing the table entries
their structure  is  based  on  running  through  the  table
entries.

     We shall call each array  of  entries  a  table  or  an
object.   There  is a routine, usually with a name ending in
_obj, which is designed to process an object.   For  example
en_obj is the routine called to generated an encoded object.
Then there are routines to call on each compound  type  such
as en_seq for encode a SEQUENCE.  Finally all the primitives
are handled by a one function that ends in _type.  This lets
each routine concentrate on handling the features particular
to its type and call the appropriate routine to handle  each
type it finds with in its compound type.

     Most of these table processing routines have just three
arguements: which are called parm, p, mod.  The parm is char
* or char ** in the encoding and decoding  routines  respec-
tively.   This points to the user's C structure that data to
be encoded is taken from when encoding.  When decoding it is
the address of a pointer which is made to point the C struc-
ture filled with the decode data.   The  freeing,  which  is
based  on  the  decoding  routines,  has a char ** while the
printing routines don't look at the user's data and so don't
have  such  a  pointer.   The  p points to the current table
entry we are up to processing and the mod  arguement  points
to  the  modtyp structure for the current module we are pro-
cessing.

     All these processing routines return a PE  type,  which
is  defined  in ISODE's file _h/_p_s_a_p._h, and to return zero if
they have an error, but not always.  In fact the error  han-
dling  is needs some work and has not been tested very well.
Generally it tries to print out the table entry where  some-
thing went wrong and the name of the function it was in.  It
then sometimes does an exit which may not be  very  pleasent
for the user.

_1._2._2.  _T_h_e _e_n_c_o_d_i_n_g _r_o_u_t_i_n_e_s - _e_n_c._c

enc_fThis is the the routine made available to the user  for
     the  encoding  routines.   It  is  fairly  simple as it
     leaves all the hard things up to other  routines.   All
     it  does  is  use the type number and modtyp pointer to
     get a pointer to the  table  for  encoding  that  type.
     Then  it  calls  the  table or object encoding routine,
     en_obj, on that object.  It first  does  a  consistency
     check  of making sure the first entry in the table is a
     PE_start.  Note that  it  returns  an  integer  (OK  or
     NOTOK)  instead  of a PE pointer.  This is to be consi-
     tent with ISODE functions.




                      January 23, 1990





                           - 14 -


en_objWe loop through the entries until we come to  the  end
     of the table and then we return the PE we have built up
     from the user's data which is pointed to by  parm.   In
     looping through each entry we call the appropriate rou-
     tine to encode its data.  The default case  is  handled
     by  calling  en_type which takes care of all the primi-
     tive types.

     The macro NEXT_TPE sets its arguement to point  to  the
next type in the table, counting compound types as one type.
Thus if NEXT_TPE is called on a SET_START it will  skip  all
the  entries  up  to  and including the matching PE_END.  As
many objects consist of one compound type and its components
the  main loop will only be run through once.  Even when the
object is not based on a compound type it will then  consist
of  one  simple  type  which  is processed by en_type, again
probably going through the loop only once.  In fact the only
way  it can go through the loop more than once is to process
entries that subsidary to the main type, e.g.  ETAG  entries
and  things  like  that.   To  double check this is the case
there is some code that looks for  the  processing  of  more
than one data generating entry.

     Much of that testing could probably be eliminated  with
no  loss.   Similarly  prehaps the IMP_OBJ and ETAG could be
handled by the default action of calling en_type.  As  these
routines  have  evolved  after many changes there are things
like that which really need to be looked at  closely  before
trying.   The comment /*SUPRESS 288*/ means suppress warning
288 to saber C debugging tool that we use.

en_type
     This is one of the longest functions as it has so  many
     cases  to handle.  It again is structure as a loop over
     the types until PE_END but it actually returns as  soon
     as  it  has  encoded the next type.  We can now look at
     the encoding of the primative ASN.1 types in detail.

DFLT_FBecause we have arranged  that  for  encoding  tables,
     that  we  precede  the entry with a DFLT_F entry we can
     neatly handle all the default  cases.   All  we  do  is
     check  if  the  parameter  passed  in the user data, in
     parm, is the same as the default value specified in the
     DFLT_F  entry.   The function same performs this check.
     If it is the same don't encode  anything  just  return,
     otherwise continue on and encode it.

ETAG To handle explicit tags we merely allocate  a  PE  with
     the right tag and call en_etype to encode its contents,
     which are in the following entries.  The switch on  the
     pe_ucode  field  use to make a difference but now it is
     meaningless and should be cleaned up.

SEQ_START, SEQOF_START, SET_START, SETOF_START



                      January 23, 1990





                           - 15 -


     We merely call the appropriate  function  handle  them.
     Note  one  _i_m_p_o_r_t_a_n_t  difference  in  the  way they are
     called here from that in enc_obj, the parm arguement is
     used  as a base to index off and fetch a new pointer to
     pass the next function.  This seemly bizarre action  is
     quite  straight forward when seen written as it is nor-
     mally in C, "parm->offset".  Where the field offset  is
     a  pointer  which  has  an offset from the start of the
     structure of p->pe_ucode bytes.

     This is the magic of how we access  all  the  different
fields  of the C data structures with the one piece of code.
It is also prehaps the most critical dependency of the whole
system on the implementation of the C language.  As the BGNU
C compiler supports this feature then it is compilerable  on
most machines.  But any porters should pay attention to this
to ensure that thier  compiler  is  happy  generating  these
offsets and compiling these casts properly.

     The reason why this is  different  from  the  calls  in
en_obj  is  that  this is not the first compound type in the
table.  The first and only the first does not have an offset
and  does  not  need  to be indirected through any pointers.
All the compound types inside this type will have  as  their
field  a  pointer which points to a structure.  From here on
we shall say _i_n_d_i_r_e_c_t_i_o_n  to mean this adding  the  pe_ucode
field to the pointer to the structure and using it to refer-
ence a pointer.  Whether to use _i_n_d_i_r_e_c_t_i_o_n or not  is  very
important  matter  that  really  needs  to  be understood to
understand how the routines are structured.

IMP_OBJ
     Here we have to handle the case where we can encode the
     object  then  have  to  change  its tag and class after
     encoding.  At the end of this entry this is  done  very
     simply by assigning the right values to the appropriate
     fields after the object has  been  built.   This  means
     that if the intermeadiate form is altered this piece of
     code may have to be altered as well.  There seems to be
     no better way of handling this.

     The complication in handling this field is the handling
of  all  the possible types of object.  If it is an external
object we have to perform a call to enc_f with all the right
arguements  where  a  normal  OBJECT,  the last else branch,
requires a normal call to en_obj.  Note the case of  SOBJECT
is the same as OBJECT _e_x_c_e_p_t _t_h_e_r_e _i_s _n_o _i_n_d_i_r_e_c_t_i_o_n.

SOBJECT and OBJECT
     Here is the code that handles the two cases  sperately.
     It  is  exactly as in the IMP_OBJ case except seperated
     out.  Note the only difference between the two cases is
     lack of indirection in the SOBJECT case.




                      January 23, 1990





                           - 16 -


CHOICE_START
     This is exactly  as  all  other  compound  types,  like
     SEQ_START  and  OBJECT, we call the appropriate routine
     with indirection.  From reading the ISODE manuals  that
     the  ASN.1 CHOICE type is handled by a structure of its
     own like the other compund types.

EXTOBJ and SEXTOBJ

















































                      January 23, 1990