tables.ms

来自「ftam等标准协议服务器和客户端的源代码。」· MS 代码 · 共 354 行 · 第 1/2 页

.NS 2
The structure and meaning of the tables generated from the ASN.1 grammar
.XS
The structure and meaning of the tables generated from the ASN.1 grammar
.XE
.PP
Each collection of \fBASN.1\fR grammar is called a module.
(See 
.[
ASN.1
.]
)
Each \fBASN.1\fR module is completely specified in the program by a
single \fBC\fR structure of type \fBmodtyp\fR and the data which it references.
See the \fIpepdefs.h\fR file in the \fIpepsy\fR directory.
For each \fBASN.1\fR module
there are three tables that are generated from\fBASN.1\fR grammar.
These initialised 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 \fBmodtyp\fR structure.
.PP
Each of these pointers references an array of pointers,
one pointer for each \fBASN.1\fR type defined in the module.
The position of one of these pointers is the unique type number we give to
its corresponding type.
The pointer references an array of type \fBtpe\fR or \fBptpe\fR, depending
whether it is an entry in the decoding/encoding tables or printing tables
respectively.
See \fIpep.h\fR in the \fIpepsy\fR directory.
This array actually contains the necessary information to encode/decode/print
that \fBASN.1\fR type.
So given the \fBmodtyp\fR structure of an \fBASN.1\fR module and its
type number you can call a routine to encode, decode or print that type.
.PP
The rest of this document assumes a good knowledge of \fBASN.1\fR notation
so go read a copy if you haven't already.
From here on I shall mention only \fBtpe\fR and this means \fBtpe\fR in the
case of encoding or decoding and \fBptpe\fR in the case of printing, unless
otherwise stated.
Each type is represented by an array of \fBtpe\fR (or \fBptpe\fR for printing).
The basic element consists of four integer fields,
the printing table is the same with an addition \fBchar\fR pointer field which
contains the name corresponding to that entry in the \fBASN.1\fR grammar.
The first specifies the type of the entry and determines how the
rest are interpreted.
The possible types are listed in \fIpepsy/pep.h\fR.
Each type is an array which starts with an entry of type \fBPE_START\fR
and ends with one of type \fBPE_END\fR.
Each primitive type requires one entry to specify it,
apart from possible \fBPE_START\fR and \fBPE_END\fR used to specify the start
and end of the type.
Constructed types are represented by a list of entries terminated by an
entry of type \fBPE_END\fR.
As \fBASN.1\fR types can be nested inside so will the
representation in \fBtpe\fR entries be nested.
For example the \fBASN.1\fR type definition:
.nf
           Example1 ::=
                   SEQUENCE {
                       seq1 SEQUENCE {
                                an-i INTEGER,
                                an-ostring OCTET STRING
                            },
                       a-bool IMPLICIT [0] BOOLEAN
                   }
.fi
.ce 1
Will generate an encoding array:
.nf
static tpe et_Example1Test[] = {
	{ PE_START, 0, 0, 0 },
	{ SEQ_START, 0, 16, FL_UNIVERSAL },
	{ SEQ_START, OFFSET(struct type_Test_Example1, seq1), 16, FL_UNIVERSAL },
	{ INTEGER, OFFSET(struct element_Test_0, an__i), 2, FL_UNIVERSAL },
	{ OCTETSTRING, OFFSET(struct element_Test_0, an__ostring), 4, FL_UNIVERSAL },
	{ PE_END, 0, 0, 0 },
	{ BOOLEAN, OFFSET(struct type_Test_Example1, a__bool), 0, FL_CONTEXT },
	{ PE_END, 0, 0, 0 },
	{ PE_END, 0, 0, 0 }
	};

.fi
.PP
Here the second last \fBPE_END\fR matches and closes off the
first \fBSEQ_START\fR.
The entries which correspond to the other primative types are pretty
obvious, with the INTEGER entry corresponding to the primative INTEGER.
For fields that generate data the general interpretation of the other three
fields is offset, tag and flags/class fields respectively.
.IP offset
The second field gives the offset in a \fBC\fR data structure
needed to reference the data that corresponds to this table entry.
Each \fBASN.1\fR type has \fBC\fR structure types generated as described in
the 
.[
ISODE
.]
manuals, volume 4 "The applications Cookbook" Section 5.2,
"POSY Environment".
As this offset may have to be determined in a compiler dependent manner
a \fBC\fR preprocessor macro is used hide the actual details.
.IP tag
This is the tag associated with the \fBASN.1\fR type for that entry.
Notice that in the example the [0] IMPLICIT which changes the tag
associated with the BOOLEAN entry actually has the correct tag of 0 in the
table.
Likewise SEQUENCE has the correct tag of 16 in its \fBSEQ_START\fR entry
and so on for the others.
.IP flags/class
This contains the \fBASN.1\fR class associated with the entry's type.
That is UNIVERSAL for all except the BOOLEAN type which is CONTEXT class.
This fourth can also contain flags that specify if the type is OPTIONAL
or DEFAULT.
There is plenty of room here as there is only four possibly classes.
.PP
Now that you have some idea of how these arrays are arranged for a type
definition I will proceed to go through the possible type of
entries and describe what they do and how they work.
These values are defined in \fIpepsy/pep.h\fR.
Those entries with a value below \fBTYPE_DATA\fR are entries that
don't correspond to data to be encoded/decoded and are for other book keeping
type purposes.
.IP "PE_START and PE_END"
As explained above \fBPE_START\fR starts the beginning of a \fBASN.1\fR type's
array.
It probably isn't necessary but the size of the tables is so small it isn't
much of an over head to keep around for cosmetic reasons.
The entry type \fBPE_END\fR is necessary to mark the end of some
compound type as well as the end of \fBASN.1\fR data type.
.IP "XOBJECT and UCODE"
These are obsolete types and probably should be removed.
They were to allow \fBC\fR code written directly by the user to be incorporated
into the encoding/decoding but it was found unnecessary.
Prehaps some brave soul would like to use them in an attempt to implement
a similar system based on \fIpepy\fR which is what we first attempted to
do until we found this to be much easier.
.IP MALLOC
This field only occurs in the decoding tables.
It specifies how much space to malloc out for the current \fBC\fR structure
it is just inside of.
For instance in the example above the decoding table has the following entry:
.DS C
{ MALLOC, 0, sizeof (struct type_Test_Example1), 0 },
.DE
just after the first \fBSEQ_START\fR entry.
It tells it to \fBmalloc\fR out a \fBstruct type_Test_Example1\fR structure
to hold the data from the sequence when it is decoded.
.IP SCTRL
This entry is used in handling the \fBASN.1\fR CHOICE type.
The \fBC\fR type generated for \fBASN.1\fR CHOICE type is a structure with
an offset field in it and a
union of all the \fBC\fR types present in the CHOICE.
Each \fBASN.1\fR type in the CHOICE of types has a \fBC\fR type definition
generated for it.
The union is of all these types, which is quite a logical way to implement
a CHOICE type.
The offset field specifies which possibility of interpreting the union
should be used (which \fImember\fR should selected).
As such it needs to be read by the encoding routines
when encoding the data from the \fBC\fR data structures
and to be set by the decoding routines when it is decoding the data into
the \fBC\fR data structures.
There is one such entry for each \fBCHOICE\fR type to specify where the
offset field is.
.IP CH_ACT
Another redundant entry type.
I think this was also used in code to handle \fBC\fR statements or
actions specified by the user.
It probably should be removed.
.IP OPTL
This is used to handle the optionals field that is generated by
\fBposy\fR when optional types that are \fInot\fR implemented by pointers
are present in the \fBASN.1\fR type.
For example if an \fBASN.1\fR type has an optional integer field how
does the encoding routine determine if the integer is to be
present or not?