CA 02228593 1998-03-03
COMP~JTlN~r .~'STEM FOR PE;~OC~.';;~ING ~POP~/fAT~ Fl.O~
RE~ATFn APPLICATION~S
This ap~}lic~ti-~n cla~ns priori~ to U.S. Provisional Appli~ation Seri~l No
60~003,786 filed on ~eptember 15, ~95 inc~lporated ~y refcre~;e.
5 P~ KGROU-ND OF TE~E TNVE~T10~
In~o~mation flows ~it~in or ~e~w~n _~mputers mus~ h~ve a structure that
a~lows m.~anIng to be extrac~ or~er w be use.~l. 1 he ~nco~ing o~ ~he in~o.~nation
is gen~rally tcrm~d its syntax and the {erm sem~ntlcs is use~ for the mt~nin,~ or the
informaiion, ~hich may ~mply aclions ~o be taken. Th~ ir.forrnation flows are .rna~
10 an~ ~ario~s; usually sp~ific non-g~neral me~ods are a~soci~ud ~ h the processino
of each type ~nd level of such flows wi~n th~ computer.
~ o generalize ~he prowcols, th~re is needed a general way to hcok ~he Syr.~.~
of a proLoco~ (what it looks l~e Pon ~he wire") to the s~ nt;c~ ot the protocol (how it
is proc~scd). This can be don~ by creating r~ur.~ive ro~tit.2es ~hat ill~o~e each c~er
15 io do ~he processing. Tha~ priol a~ techniqu~ is difficult to ~roO~m, expe~iv~ of
cornp~ler resources, and !lifflrlllr to genf~rali7e.
On~ example of an explici~ ~rchitcctllre ~or constructing and Gomposing
n~wvr~ protocols is cl;sc~ss~l hy N.C. Hutchinson and Larry L. Peterso~ The Y-
Kern-l: An Arehit~c~lre for rmp~e~nentin~, Necwor~c Proloco~s" (~E~ Trans. Sorrw2re
20 Eng., ~ol. l7~ ). This architec~ure ~efi~; pr-~toccis, s~ssions ~nd ~essag~
~ o'oject~. The ke~qel s~pards messa~es thrGuc~h a ne~ork 0~ pro.ocol ~nd ~s3ionobj~cts. Th~ou~h tLhis p~ocess, mess~ge he~d~r~ a~e a~led or stripped f~om the ~and messages can be man~pulated. The x~kernel ~r~h;tec~re requiles ~t supp~rted
prot~ol~ be created and in;ri~li7ed in a h~erarchie~l or~er.
A~ i'lD~D SH,FFT
CA 02228593 1998-03-03,, .,., .",. ., ,, ,,,", , , ~
~ . . . .. ; , - ; _ ,, _ _ ,,, __,, _,, , , . , _ ,,, _,, _ _ _ , _ . . _
SIJMMAl~ C)F T~F. r~F~NTION
Fr~ are a ge~ral w~y of repr~enr;~ in~rmat~on ~n~l its stmcture in
artificiaL iz~tellige~ce system~. Essenei~lly, a fram~ is a se~ ~f at~ributes and ~2ch
5 attribu~ in a fr~me has a ty~e a~d a value. Fur~ermorc, ~n~ ~ttnbute c~- irsel~ be
f~me. Many or the infc~ n ~ows within or b~tween comput~rs can be
r~presente~l as seg,uences OI ~rames.
- ,~t,;E'~!5~!' SHEE
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 ~
A general &p~)a a~uS and method in accol~ce with the i~ Lioll processes
il,rc,~ ;0,. flows which can be ~ o~nled as Se~ .Jll'~;~ of frames. r~,rc.i~d
embo(1imlo-nte of the invention ~ O~ te the cn---~ acelss;~ of frames in a
single proce~ing engine that can ~rr~ ly handle uJLo. .~ nn flows ~osOes~ a
S wide variety of syntactic and sem~ntir ~ lic~. Pn,rcl~cd embotlim~nts deal
abstractly with the hlr~ on flows, relying on one class of lower level rouLil,cs(termed 'adapter ~ulilles') to provide inputs and on other classes of lower level
routines (termed 'action routines') to implement any collCl.,lc actions n~c~ / to
~rcornI~lish the procç~~ing task. By ~c~rolll~il~g the ~liffir7l1t iterations and rec~lr.~ion~
10 in the general engine, the adapter and action ~)uLilles can be made simpler and
smaller and thus easier to program.
Preferably, the proce~sing engine inrl~ es a common core engine and a
plurality of support routines. The support routines operate on at least one
hierarchical memo~ store, such as a stack of attributes and a stack of frames. The
15 support luu~ es can also gen ,~ oyll~ LiC attributes for storage in the stack of
attributes. In addition, the proce~ing engine is preferably r~ and capable of
multi-threading .
The information flows can lc~l~sell~ various kinds of information. The
information flow can be a protocol-based stream of data between colll~u~10 for
20 il~Lc~c~ ult;r co~ ;on~. The information flow can also lcplesellL
intracol,l~uLer co-llll,ll,.ir~tinn~, such as co~fi~.~.alioll and el,vi~ llent h~ollllaLion.
The processin~ engi~le can also be viewed as a l~n~l~ge processor.
BRIEF DESCRIPTION OF THE DRAWINGS
The forcgoi- g and other objects, r~lulcs and advantages of the invention,
25 including various novel details of col~.LIu-;lion and combination of parts will be
apparent from the following more particular dl&wulgs and description of preferred
embodiments of the CUlll~u~ g system for processing information flows in which
like reference characters refer to the same parts throughout the different views. It
will be understood that the particular a~a,alus and methods embodying the
-
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 -
--3--
invention are shown by way of illustration only and not as a limit~tirm of the
invention, ~ h~ instead being placed upon ill~ n~ the principles of the
invention. The principles and features of this invention may be employed in various
and numerous embotlimlont~ will~ut departing from the scope of the illV~ iOll.
FIG. lA is a block ~ gr~m illU~iLldl ug a prior art system for illL~ ing
il~ol ~ tion over a colll~uLe. lletwolk.
FIG. lB is a representive electronic mail m~s~e processable by the prior
art system of FIG. lA.
FIG. 2 is a simplified block diagram illu~ Liug a basic embo-lim~ont of the
10 invention.
FIG. 3 is a more ~l~t~ilecl block diagram of a ~ r~l.ed embodiment of the
invention.
FIG. 4 is a schem~tic rli~gr~m of a ~.~;re..ed embodiment of an initi~li
memory store.
FIG. S is a scchPm~ti~ gr~m of a l~.cs~ ive memory store of FIG. 4
with data stored therein.
FIG. 6 is a schPm~tir diagram of the memory store of FIG. 5 after
invocation of the 'endFrame' routine 125 of FIG. 3.
FIG. 7 is a sch~m~tic diagram of the memory store of FIG. 6 after
invocation of the 'setAttribute' routine 135 of FIG. 3.
FIG. 8 is a sch~m~tir diagram of the memory store of FIG. 7 after
invocation of the 'upAttribute' routine 145 of FIG. 3.
FIG. 9 is a block diagram of a ~IGfelled embodiment of t_e invention
employing parallel proce~ing and pipelining techniques.
FIG. 10 is a block rli~r~m of a memory construct for the system of FIG. 9.
DETAILED DESCRIPTION OF PREFERRED
EMBODIMENTS OF THE INVENTION
FIG. lA is a block diagram illusllaLing a prior art system for interch~nging
information over a co~ ul~l neLwolk. As illustrated, two col~ul~ls 1, 2 are
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663 -
çx~ illfo~ ........ .over a e~ w~ 3, sueh as F.~ , which has its
own d~fin~ co.n.... i.-~l;rJf~ ~lo~oeols. The first ec.~ nr~ es layers of
proeedures to ~.. Q~ the data from the lleLwcllh plolucol into hlrc.. ~ ion whieh
- can be ~lcsellLed to a user. As illn~tr~t~l the eol~uL~l~ 1, 2 have i~1entic~l int.orn~l
5 proce(lllr~l layers. However, the two co..~ 1, 2 may typieally tr~n~l~t~- through
dirr~lcllL layers of protoeols. FIG. 2 is a l~l~s~llLive eleetronic mail messageprocessable by the prior art system of FIG. lA.
Briefly, a ll~Lwolh interface routine (NIF) lCCeiVt:S the i~o~ n flows
from the ~ wo~h and proeesses the network protocol layer. A Tl~ ion
10 Control Protocol (TCP) procedure processes the TCP layer. A Simple Mail
Transport Protoeol (SMTP) proeedure proeesses the SMTP layer. An RFC822
procedure processes the mail protocol layer. Finally, a user proeedure then displays
the information to the user. Messages created by the user are converted by the
respective colll~uLt;L pluce-luic;s into the network protocol for tr~n~misQion across the
15 network 3 to the clestin~tic)n com~uLer.
Pl~f~ d embo~ of the co~ uLillg systems in accordal1ce with the
invention facilitate the seL,~ ion of the ~ aly task of ~locecci..g an a~l~lia
information flow into three distinct subtashs, one of which is a processing engine
that is Ulli~ ~L~ally applicable to all such illrol.naLion flows.
The i-lro.ll.ation flows can be viewed as frames as defined by Marvin
Minsky, "A Framework for R~l.,se~ g Knowledge," in l~e Psychology of
Computer Vision pp. 211-277 (P.H. Winston ed., McGraw-Hill) (1975). As used
herein, a frame is a collection of attributes and an attribute has a name and a value.
An attribute can also be a frame, which creates recursion.
FIG. 2 is a schPrn~tir block diagram of a basic embodiment of the invention.
A proces~ing en~ine 10 has as its responsibilities: 1) validation that the hlrullllation
flow is a seql~P~re of frames, and 2) the primary control logic inrlu-lin~ iteration
and recursion to process the sequence. At least one adapter routine 20 is responsible
for sc~ g an incoming information flow Ii, recognizing frame bo~ln-l~ries and
attributes, and .~ign~lling the processing engine 10 as they are encuullL~l~,d. A
-
CA 02228593 1998-03-03
W O 97/12339 PCTnJS96/14663 -
plurality of action r~u~iues 30 are responsible for implf~..,r..~ the actual ~ CÇ~;..g
of the cc~ oll~n~ of the i~rullllaliûn flow Ii when acli~,ated by the pluce~
engine 10. The action l~u~ es 30 can also gc~cl~c outgoing illro....~l;on flows Io~
which can be l~ cul;jivcly processed through an adapter routine 20.
While the proc~in~ engine 10 is a general purpose procedure which is
olL~ble to ~lirr ~ L co~ ulcl~, the adapter routine 20 and the action r ~uli~es
30 are specifically written by a prog~ for the target C(~ JulCl. Preferably,
there are multiple adapter r.~uli~es 20, each specifir~lly written for a particular
protocol. As will be shown below, the ~rocç~ engine 10, the adapter l~u~ es
20 and the action routines 30 are very simple to program because the illCOlllill~g
information flows I; are treated as sequences of frames of data.
FIG. 3 is a sch~m~tir block diagram of a pl~rc~lcd embodiment of the
invention. In the figure, the larger arrows l~lcsenl control signals and the smaller
arrows ext~ lin~ from dots l~)lC:iellL data flow. General purpose routines of the
proces~ing engine are shown lln~h~AçA, whereas non-general purpose l~u~hles
(specifically programmed for the e.lvhul~ elll) are shown shaded in the figure.
The procç~ing engine 10 is illll~tr~t~A as having two major components, a
reentrant frame processor (FRAP) 12 which acts as the core engine and multiple
memory contexts 100. The procçs~ing engine 10 co"""ll"ic~tes with multiple
context-linked adapter routines 20, which receive multiple incoming information
flows Ii, at least one information flow per adapter 20. The processing engine 10 is
triggered by multiple potential caller routines 50. Typically, each caller routine 50
acquires at least one context to avoid conflicts. The procçssing engine 10 also
collllll~ tes with general purpose action routines 30 and special context-linkedaction routines 60, 70, 80.
Briefly, each memory context 100 is m~int~in~ by a plurality of support
routines. The support routines include a 'putFrame' routine 5, a 'putAttribute'
routine 110, a 'startFrame' routine 115, a 'processAttribute' routine 120, an
'endFrame' routine 125, an 'initContext' routine 130, a 'setAttribute' routine 135, a
'getAttribute' routine 140, an 'upAttribute' routine 145 and possibly other support
-
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663 -
--6--
uuLiues shown glo-n~r~lly as 150. Each adapter routine 20 is as~ociaL~d with a
l~s~ec~ive memory cont~Yt As ill~ 1, the first adapter 21 l~;V~S an
i~c,. .,.~ on flow I2l and is associaled with a l~sl ecli\~ Oly contoYt 101.
Likewise, a second adapter 22 lecei~s an hlr)~ ion flow I22 and is a~social~d
5 with a l~,~e~;liv~ ~ClllOl,y context 102.
Also illustrated are 'checkFrame' l~uLiues 60, 'initFrame' loulil~es 70 and
'finishFrame' routines 80. Each ;...~ e of these special action lvuLines are
associated with a respective lueluoly context and adapter pair. For example, thefirst adapter routine 21 is ~Ccoci~t~d with a first lllClllUl~ cûnteXt 101, a first
10 'checkFrame' routine 61, a first 'initFrame' routine 71, and a first 'finishFrame'
routine 81. When ruulilles are invoked, the specif~c routine called depends upon the
context. In the case of memory, the hieldrcllal memory store used also depends on
the context.
The general purpose action routines 30 can also create outgoing i lrolllla~ion
15 flows Io which may then wrap around and be processed through another invocation
of the frame processor 12. This is typically accomplished by an action routine 30
invoking the frame ~rucessol 12 again in the role of a caller routine.
Proceccing begins from a caller routine 51. The caller routine 51 first
invokes an 'initContext' routine 130 to create a new context and associate the
20 various loulilles, h~rollllalion flows, and memory with that context. A unique
identifier for the context is l~l.. Pcl to the caller 51. The caller 51 then triggers the
frame processor 12 and passes the context. The frame processor 12 then signals arespective adapter routine 21 which is mo..;l~..;.~ an incoming information flow I2l.
The adapter routine 21 signals the frame ~r~ces~ 12 with a START_OF_FRAME
25 or an END_OF_FRAME or an ATTRIBUTE signal.
Upon receiving a START_OF_FRAME signal, the frame processor 12
signals the respective 'startFrame' routine 115 passing the context. The 'startFrarne'
routine 115 retrieves the current and new frame names from memory. The
'startFrame' routine 115 then invokes a respective 'checkFrame' routine 61 passing
30 the context, the current frame name and the new frame name. The 'checkFrame'
_
CA 02228593 1998-03-03
W O 97/12339 PCT~US96/14663 --7--
routine 61 may also call other action routines 30 passing the context, current frame
name and new frame name.
The 'startFrame' routine 115 then makes the new frame the current frame
and invokes a ~c~e~;liv~ 'initFrame' routine 71 passing the cont~oxt, the current
5 frame name and enclosing frame name. The 'initFrame' routine 71 mLay also callother action routines 30, passing the context, current frame name and enclosing
frame name.
The frame processor 12 may then receive an Al~IBUTE signal from the
adapter routine 21. In les~o~e to the ATTRIBUTE signal, the frame processor 12
10 invokes the 'processAttribute' routine 120, passing the context, to store the attribute
in memory.
The frame processor 12 may next receive an END_OF_FRAME signal from
the adapter routine 21. In response, the frame processor 12 invokes the 'endFrame'
routine 125 with the context. The 'endFrame' routine 125 retrieves the frame name
1~ from the memory co3~text and invokes the 'finishFrame' routine 81. The finishframe routine 81 is passed the context and frame name. The 'finishFrame' routine81 also invokes action routines 30, passing the name and context.
As can be seen, the frame processor 12 keeps track of signals. Indeed, the
frame processor 12 does not receive any values, only signals. By using context
20 memory the frame processor 12 can be made reentrant and multi-threaded. These and other routines will be described in more detail below.
The memory context is a llie.~ ical memory store having a unique
iclentifier. Each memory context m~t~hP.c two stacks: a frame stack and an attribute
stack. Each attribute is associated with a frame. In the stacks, the most recently
25 stored and therefore most likely to be needed aLllibul~s are at the top of the stack,
where they are readily available for procPssing. If further attributes are needed and
they are not supplied with the top frame, the stacks can be sc~nnP-l from top tobottom to inherit the attribute from below (i.e., an outer frame layer). A context
has three associated information streams: an input stream, an output stream and an
-
CA 02228593 1998-03-03
- W O 97/12339 PCTnUS96/14663
--8--
error output stream. It should be noted ~at context memory 100 is not ~cessA~
for the invention, however the use of context ~elllGl~l 100 offers certain advantages.
Basic Grammar
This i~ i...re of the L)roces~i..g system co~ e~ a formal ~ which,
5 although e~ ssed here in Fn~ h, can be tr~n~1~te~l directly into an execllt~ble
cou.~uLer procedure by any of several gl~lldl tr~n~l~tors such as YACC or
BISON. This is one of many equivalent ways of creating a CO111~UI~1 procedure that
implem~nt~ the proces~ing engine 10. P~,se,lltd are the elem~nt~ of the g,~,~
together with expl~to"/ commentc that are not a part of the ~.,.. ~
In the ~l~ar, words in quotes l~)lc~selllessr~ l elem~ntc of the g~
with particular m~o~ning~: 1) words that are all capitals ,~se~lL input signals to the
proce~ing engine from the adapter routine; 2) words that are mixed case and begin
with a capital are used internally within the ~locessil-g engine and are derived from
the inputs through the rules of the ~,~"~n~, and 3) words that are mixed case and
begin with a lower case letter are routines that are invoked by the frame processor
12.
1. A 'FrameList' is:
a. a'Frame'
or
b. a 'Frame' list followed by a 'Frame'.
A 'FrameList' is a se~l~nre of frames which may consist of just one
'Frame'. Rec~ e this is the first rule, the resnlting colll~ul~r procedure will expect
that its entire input information flow can be categorized as a sequence of frames and
will return an error if this is not so. This rule provides the first level of iteration in
25 the control structure of the processing engine 10.
CA 02228593 1998-03-03
- W O 97/12339 PC~US96/14663
_9_
2. A 'Frame' is:
a. a 'START_OF FRAMF' (execute t7ne 'startFrame' routine) followed
by a 'SubFr~m~T;ct' followed by an 'END OF_FRAME' (execute the
'endFrame' routine)
or
b. a 'START_OF_FRAME' folowed by an 'END_OF_FRAME'
(execTlte the 'startFrame' routine then execute the 'endFrarne'
routirle).
A 'Frame' has a start ('START_OF_FRAME') and an end
10 ('END_OF_FRAME') and optionally CO~ ~ a 'SubFr~meT ict'; rouLines
('startFrame' and 'endFrame') are ext?c~lte~l at the ~pl~li~L~ times as directed by
~e gldlll,llal.
3. A 'SubFr~m~T ict~ is:
a. a'SubFra7ne'
or
b. a 'SubFrameList' followed by a 'SubFrame'.
A 'SubFrameList' is a seq77~nre of SubFrames wllich may consist of just one
'SubFrame'. This rule provides the second level of iteration in the control structure
of ~e processin~ engine 10.
20 4. A SubFrame' is:
a. a'Frarne'
or
b. an 'ATTRIBUTE' (execute the 'processAttribute' routine).
CA 02228593 1998-03-03
~ W O 97/12339 PCTAUS96/14663 -
--10--
A 'SubFrame' is either itself a 'Frame' or it is an 'Attribute', in which case
the action routine 'processAttribute' is invoked. This rule provides the rec~r.~ion in
t_e control structure of the ~)l'OCe~ engine 10.
The above ~ldlllLUal iS now written below in a l~n~l~ge that can be pr~cessed
into an e~cPcut~hle program. The vertical bar ( ¦ ) r~lcscllL~ "or" in the language
and routines being invoked are placed inside braces ({}).
1. Fr~meT.ict- Frame ¦ Fr~mPT ;~t frame
2. Frame: START_OF_FRAME {startFrame0;} SubFr~meT.i~t
END_OF_FRAME {endPrameO;}
¦ START_OF_FRAME END_OF_FRAME {startFrame ();
endFrameO;}
3. SubFr~meT i~t- SubFrame ¦ SubFr~meT ict SubFrame
4. SubFrame: ATTRIBUTE {processAttribute ();} ¦ frame
Rec~ e an attribute is really a type and a value, the rules can be e~rten~1pr1 to
1~ so define an ~LL.ibuLe. However, ~ the rules to include types and values
can complicate the task of processin~ the i,lro~ ion flows. For that reason, therules are not extPn~lP~l in this embo-limPnt
Primary Supplements to the Basic Embodiment
As briefly described above, the basic embodiment described with l~erellce to
FIG. 2 can be supplemP~t~l with general purpose action routines that facilitate the
processing of frames and their hlLlibuL~ s. Turning to FIG. 3, most of these
supplemPnt~l rouLil~es are private, which means they can only be invoked by the
processing engine itself. One routine is public, which means that non-general action
routines may invoke it.
In some cases described below, the invocation of an action routine associated
with a frame is l~;Çt:.enced. There are many ways to perform such an associationincluding: associating all frames with one such routine, using the name of the frame
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 --
to ~lel~ P- a routine to invoke, using the available ~ s of the frame to
....i.lf. the routirle, etc. M~kin~ a eolL~o~ P~-re beLweell frames and object
classes in an object-oriented pro~ ---;-- ellVilLOlllllelll iS another way to provide the
association. These l~u~ es work with frame names and with alLlil~uLe names and
S values; any or all oi: these items may be complex, i.e., consist of an associated
collection of data items, anyl of which may also be complex.
The private 'startFrame' support routine 115 first calls a non-general action
routine (e.g. 'checkFrame' 61) and passes it two values: the name (if it has one) of
current frame and the name (if it has one) of the new frame being started. The
name of the current frame is derived from the hield~;cllical memory store of frame
names described below. The name of the new frame may have been passed from
the adapter routine 21 to the proces~ing engine 10 and then to the 'startFrame'
routine 115 or it may have been made available in some other way to the routine,but in any case it is provisionally stored in memory at this point. The purpose of
calling the 'checkFrame' routine 61 is to allow a routine associated with the current
frame to be executed prior to the full initi~ tinn of the new frame. Such a routine
can perform any sort of proc~e~ing and might typically check the validity of
proces~ing the new frame within the current frame. If the 'checkFrame' routine 61
returns an error, then the 'startFrame' routine 115 may cause the new frame to be
skipped, including its attributes and any contained frames to any depth.
If wallallLtd by the degree of success of the preceding steps, the 'startFrame'
routine 115 next triggers the ~ellllallLt;llL storage of the name of the new frame,
which then becomes the current frame. Frame names are used to dyn~mir~ly
construct a colll~u~e~ memory space that CO11L~LL1S the name of the active frame at
each hierarchical level. The current frame is at the highest level and the lowest level
is always occupied by an implicit frame, typically named 'ROOT', which logicallycontains all the other frames and is present upon initi~li7~tion of the system and
support loulilles.
FIG. 4 is a s~hPm~tic diagram of a ~ r~ d embodiment of an init~ rd
~ 30 memory store. The cc,lll~uL~r memory space compri~es a hierarchical memory store
CA 02228593 1998-03-03
- WO 97/12339 PCT~US96/14663
-12-
of frame names (stack FRAM~) privately kept by the general purpose action
uuLi~es and diL~iLly ~ .le only by them. The hi~al~ ical memory store of
frame names is a~oci~tff~' with a corresponding store of attribute names (stack
ATTR) and values as described below. By default, the 'ROOT' frame is associalcd
5 with a null alLlibule 'NULL', but particular ~ulibulcs and values may be stored on
the ATTR stack and assoei~lcd with the 'ROOT' frame to be inh~riton by later
frames, as will be described below.
FIG. 5 is a srh~ms-~tir ~lis gram of a lc~r~s~llL~live memory store of FIG. 4
with data stored therein. The memory store of attribute names and values is
10 logically ol~ ~ as a last in-first-out stack in such a way that attribute names and
values can be s~ccessed seq~ nti~7l1y in reverse order (from last in to first out) and
such that all the attribute names and values associated with the current frame can be
removed from the stack. Like the memory store of frame names, the memory store
of attribute names and associated values is privately kept by the non-general purpose
1~ action routines and is dilc~;Lly s~rcescihle only by them.
R~tnrning to FIG. 3, the 'startFrame' support routine 115 then calls a non-
general action routine (e.g. 'initFrarne' 71) and passes it two values: the name (if it
has one) of the new frame, which is now the current frame, and the name (if it has
one) of the parent frame. The frame names are derived from the hierarchical
20 memory store of frame names described above. The purpose of calling the
'initFrame' routine 71 is to allow a routine associated with the current (new) frame
to be executed prior to the ,UlUC~ssi~g of attributes and/or w~lL~i,led frames. Such a
routine can ~ Çollll any sort of proceccing and may typically check the validity of
procec~ing the current (new) frame within the parent frame. If the 'initFrame'
25 routine 71 returns an error then the 'startFrame' routine 115 may cause the current
(new) frame to be skipped, including its attributes and any contained frames to any
depth.
The combination of the 'initFrame' routine 71 invocation and the
'checkFrame' routine 61 invocation described above provides the oppolLun~y for
30 non-general action routines associated with frames to easily enforce a hierarchy of
CA 02228593 l998-03-03
- W O 97/12339 PCT~US96/14663 -
- -13-
.)C~ w~ ,~ each frame ~l,e~ s both what frames can cnnt~in it and what
frames it can contain, and the çnr.l~ ~in~ frame always takes ~l.ces~F~ e over the
enclosed frame.
The private 'processAttribute' support routine 120 triggers the storage of the
5 attribute name and associated value in memory associated with the l~ ical
memory store of frame names. The ~LLIilJul~ name and value may have been passed
from the adapter routine to the proces~in~ engine 10 and then to the
'processAttribute' routine 120 or they may have been made available in some other
way to the routine.
The private 'endFrame' support routine 125 calls a non-general action routine
(e.g. 'finishFrame' 81) and passes it the name (if it has one) of the current frame
derived from the hierarchical memory store of frame names described above. The
purpose of calling the 'finishFrame' routine 81 is to allow a routine associated with
the frame to be invoked that will cnmI lete the processin~ of the frame, as all
collL~illed attributes and frames will have been completely processed at this point.
Upon completion of the 'finishFrame' routine, all attribute names andL values
associated with the current frame are logically removed from the memory store, the
current frame name is also removed, and the enclosing frame is made the current
frame.
FIG. 6 is a sçh~m~tic diagram of the memory store of FIG. 5 after
invocation of the 'endFrame' routine 125. Note that frame F3 and its associate
attributes A4, A5 have been popped from the stacks and the current frame is now
F2.
l~otllrning to FIG. 3, the public 'getAttribute' support routine 140 is typically
invoked from a non-general action routine ~ocj~te~l with a frame. It expects to be
passed an attribute name, then logically scans the stack of aLL,il,uL~ names and values
in reverse order (from last in to first out) until a m~trhin~ name is found or until all
can-litl~t~ attributes in the stack have been sç~nn~l If a m~trhing name is found, it
returns the associated value to the caller, otherwise it notifies the caller that the
~ 30 attribute was not found.
CA 02228593 l998-03-03
W O 97/12339 PCTAUS96/14663 -
-14-
Via the above ~ ." the ~ "~ values are logically ~ .Sf.~t~ a
hical ~cr wll~.~ the latest value stored with a particular name is always
the one ~ , o~ * any pL~ Us values ~so~ t~ with ~at name and set at
the same frame level or at higher levels. This scheme provides for il.her;l~..re of
S ~ ul~s by enclosed frames wL~~ l a frame for which the adapter routine did notprovide an attribute from the illr ~ ;on flow can inherit that ~ttrjhvte from anPnrlo.~ing frame higher in the hieldlclly and the attribute value provided is always
the closest one that is ~ocj~tPd with an active frame. ReÇ~l-i~ again to FIGS. 5and 6, the ~LLLibut~ A2 associated with frame Fl is overri(l~len by the attribute A2
10 associated with the more current frame F2. These attributes can have dirr~l~,.lL
values.
Secondary Supplements to the Basic Embodiment
Additional support routines also add useful ext~n~ions to the basic
embodiment described above, enabling the ~l~finitilm of sequences of frames and
15 their processing that can be sufficiently complex as to co~ lise a family of
C~ U~L languages.
R~ to FIG. 3, the public 'setAttribute' support routine 135 is typically
invoked from a non-general action routine associated with a frame. It expects to be
passed an attribute name and value and places them in the private hierarchical
20 memory stores shared with the other support routines, Attributes set this way are
termed synthetic attributes as they are created by action l~ uLines rather than being
received in the ..~ollllation flow itself. The 'setAttribute' routine 135 stores the
attribute in ~soci~tion with the current frame as if it were received from the
illrollllation flow. The effect of this facility is to provide a way for action routines
25 associated with the current frame to pass information to each other and to enclosed
frames via inheritance.
FIG. 7 is a sch~om~tic diagram of the memory store of FIG. 6 after
invocation of ~e 'setAttribute' routine 135. Attribute A6 is placed on the attribute
stack (ATTR) and associated with the current frame F2 (determined from FIG. 6).
. --
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 -
-15-
R~ ~ to FIG. 3, the public 'upAttribute' support routine 145 is also
typically invoked from a non-general action routine associaLed with â frame. It too
expects to be passed an alLlibuLe name and value and places them in the private
llic~ ;hical memory stores shared with the other support l(~uLi~es. However, the5 synthetic ~ttrihlltt~ thus created is associated with its imm~ to parent frame, not
with the current frame. The hierarchical memory store is adjusted so that it a~l.e
as if the synthetic ~Lalil,uLe was the last aU,ibuL~ ~eceived from the i~o. ~--~ n flow
for the parent frame and was then followed by the ~ s of the current frame
present prior to the adj~ 7L~ LOgicâlly, the set of ~ll- ;b~llre ~soci~t~A with the
10 current frame are removed from the hiel~lcl~ical memory store and saved7 the
current frame is then removed from the memory store and saved, the enclosing
frame is made the current frame, the new synthetic aLLIibuL~ is stored, the saved
frame is stored (becoming the current frame), and finally each ~ILli~uLe in the saved
set of attributes is stored in its original order.
FIG. 8 is a sc~ tir- rli~gram of the memory store of FIG. 7 after
invocation of the 'upAttribute' routine 145. Attribute A7 has been placed on theattribute stack (ATTR) and ~oc;;.l~d with the parent frame F1. The current frameF2 retains an association with its aLLlibuLes A2, A6.
One effect of this facility is the opposite of hllleliL~ce: it provides a way
20 for action routines to return values up the hierarchy so that they can be retrieved and
acted upon by action routines associated with frames at a higher level. Additionally
the synthetic aUlibuL~ can be inherited by do~vl~Ll~alll frames (frames enc~ull~e.,d
subsequently in the illro,.,.~lion flow) outside of the hic.al~;l~ical sub-tree headed by
the current frame. Through the action stated above, this routine provides a general
25 facility for resolving frames into attributes. That is, the frame, and all of its
attributes and çnrloserl frames if any, can be viewed as being replacçd in the
hlfolllla~ion flow by synthetic attributes which are set by the action of this routine.
This general facility for re~ cin~ complex information objects (frames) into
sirnpler ones (aLLlil,ul~s) and lc;~ ..i-.g results up the proces~ing hierarchy together
30 with the other support lvuLhles and the basic embodiment itself enables the general
_
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663
-16-
pr~c~x~ of iLIru~ ion flows S~rri~ r.~l1y complex that they can be considered
cc....l...t~ . languages. The ~ ~es must, however, be ~ ible as seql~n~-es offrames.
R~l.. ;.-~ to FIG. 3, other useful public support ~uuLilles 150 or special
S purpose ~LLlibul~s can make ~ ition~l facilities available to action luuLilles. For
example, one class of luuLiules can provide more ~et~ ocl and/or complete access to
the hierarchical memory store, enabling an action routine to walk tbrough the active
frames and aLLlibuL~s~ possibly l~Ll;c~i~ more det~ d i~ ion about each
eleml~nt Another class of luuLi~ es or syllLl~t:Lic ~U,illuL~s can provide ways of
10 arre-;Lillg the proceecing of fr~mes7 e.g. ski~iLIg the rem~ining ~JlUCe~ of a
frame and its attributes and enclosed frames. Another class of ~uuLilles or attributes
can allow a frame or an action routine associated with a frame to disable or modify
access to the public support luuLilles by the action luuLilles associated with enclosed
frames; this could enable a hierarchically based security scheme in which enclosing
15 frames and their action LouLi..es control the privileges of the action routines of
enclosed frames. An additional class of synthetic attributes can modify the normal
retrieval of attribute values, for example a special type of synthetic attribute could
nullify or mask the presence of an attribute from any dow~Llealll action routinewithin the scope of the synthetic attribute's associated frame.
20 Tertiary Supplements to the Basic Embodiment
Additional support routines and minor motlifie~ti~n~ to the other routines
further extend the basic embodiment described above such that it can be more
cnmp~etly implemf~nte~l, lessens the burden on programmers of action rouLilles, and
is fully reentrant and capable of multi-threading, i.e., capable of proces~ing multiple
25 information flows at one time without collision.
The public 'initContext' routine 130 takes as arguments the information
necess~ry to invoke four non-general routines: an 'adapter' routine 21, a
'checkFrame' routine 61 an 'initFrame' routine 71, and a 'finishFrame' routine 81;
and the information n~cess~ry to invoke three information flows: 'input', 'output',
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 --
-17-
and 'error output'. It initi~1i7~ a new ~ie.a.. hical m~uoly store (a memory
context) distinct from any others and returns a unique item called a context that link~
together the four lvuL ues~ the i~ l aLOn flows, and the new ~cllluly context such
that they can be used by other luuLi~cS.
S Multiple cOiltcl~ can be active at once. Each general routine and each nûn
general routine invûked by a general routine l~ivcs a context as an arg1m~ont inaddition to any other alE;UUlClll~. A new context can be grafted onto an çxi~ting
context such that the memûry store of the Px;~ context appears as an enclosing or
a superior memory l~ie.dL-;hy of the new context. Any llu llber of these collLe~L~ can
exist in parallel, de~ming a tree-structured memory cons~ l. Each thread of
e~eCl1tion establishes at least one ll-emuly cont~t The core engine m~n~es the
trees of memory context in such a way that memory can be safely shared among theext~c~1tin~ threads.
The public 'pu~rame' support routine 105 is typically invoked from an
adapter routine. It is passed the frame name and plc~alcs the memory context forstorage of the name. Similarly, the public 'putAttribute' support routine ll0 ispassed an attribute name and value and ~l~dr~,S the memory context for their
storage.
By providing direct moven,c lll of the names and values from adapter
routines, the core implementation of the processing engine l0 is simplified because
it does not need to receive the names and values, store them int~rn~lly, and pass
them to other routines. This speeds up the e~cnti~ n of the system and reduces its
int~rn~1 memory requirements subst~nti~lly.
Other useful routines could manipulate CU11l~L~. A routine could make a
copy of the conlellLs of a context, cloning the state of the hi~ cl~ical memory store
for use in a new context. Other luuti~les could be devised to merge memory
contexts.
Other supplt~mtont~ to the system in accordance with the invention address
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 -
-18-
multi-threading. Based upon cLrc-;Livc values of ~ c, the system W~ l;c~l1y
creates p~r~llel threads of eY~cntitn to ~l~,cess each frame in a se.~
A(1~1itic)n~lly~ routines allow the creation of threaded pipes to col~nc~;l the output of
one thread (as a frame seqll~nrP) to the input of another thread.
A ~l~rc,l~,d procçc~cin~ engine in acco~ e with the invention provides at
least two selvices based upon multi-threading: ;I..lo~ ;r "parallel proce~ccin~" of
serial frame sequences and pipelines of frame seq~l~nres belv~ ,n threads ("threaded
pipes"). Parallel procçCcin~ occurs z~ l;r~11y when an adapter routine receives a
seqll~onre of frames; as each complete frame is received, the general engine
~ Ps a thread of eY~ecution to process the frame and then imm~ tely invokes
its adapter routine to obtain the next frame. Due to the hierarchal nature of frames
and the l~e.l~ and lC~;Ul~.iV~: attributes of the general engine, this parallel
procecsin~ feature can result in many ~cimlllt~nPously executed parallel threads of
eX~cllti()n which execute in an orderly l,ld~el to receive and process a seqnenre of
frames. Threaded pipes dy~ ir.~11y connect the output (as a frame .seql-enre) from
the action routines in one thread of ~cl~tion to the input of the adapter routine in
another thread. This l~lcr~ d feature allows for dy~lic paralle~ tion of the
proc~,csing of s~lcc~scive levels in a complex information flow. ~f~flition~
procescin~ loulhles for each level can be kept relatively simple and r1i.ctinr.fFIG. 9 is a block diagram of a ~lcr~ d embodiment of the invention
employing parallel proce,ssin~ and pipelining techniques. Illustrated in a calling
application 100 for procescing illrollllaliol~ flows from a source 105. The
application 100 invokes the frame processor 110. The frame processor 110 can
exeCllte a first TCP adapter 120 and a plurality of TCP action routines 130a, 130b,
130c in parallel. The TCP adapter 120 recognizes a TCP request stream from the
source 105. The actual protocol is ~l-)cessed by the action routines 130. Each
action routine 130a can .oY~cute a plurality of frame processors 140a, 150a, 160a in
parallel to process the frame sequence from the source 105. Initial frame processor
140a invokes a second TCP adapter 142a which recognizes the frames from the TCP
port. Attributes from the second TCP adapter 142a are fed through a TCP frame
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663 -
--19-- .
~ ,ces~or 140a to a second TCP action routine 144a. The second TCP action
routine 144a places a seqnPn~e of parsed frames in a pipe output 146a. The
~,.lco..~ iu~ TCP action routine 130a has, for example, invoked an SMTP frame
processor 150a which removes the seq ~en~e of frames from the TCP pipe output
5 146a into an SMTP pipe input 152a. The sequence of frames are processed by theSMTP frame processor 150a using an SMTP action routine 154a which places a
parsed seq~l~nre of frames into an SMTP pipe output 156a. In addition, a MIME
frame pr~cessor 160a ~cceives the SMTP output in its pipe input 162a. These
seqll~n~e of frames are processed by the MIME frame processor 160a using a
10 MIME action routine 164a. Using a MIME pipe output 166a, ~ tion~l frame
processors can further process the sequence of frames.
FIG. 10 is a block diagram of a memory construct for the system of FIG. 9.
A memory store for the application route 210 and the memory store for the first
TCP adapter 220 are e~o",~ ed by a commonmemory context 215. Each of the
15 TCP action ~uLh,es 130a, 130b, 130c of FIG. 9 have a ~~,~ecliv~ memory store
230a, 230b, 230c which each have a respective memory context 235a, 235b, 235c asillustrated. In addition, the TCP frame processor 140a, SMTP frame processor
150a, and the MIME frame processor 160a have a respective memory store 240a,
250a, 260a which are e.lco",~ ed by a ,~,~e-;Liv~: memory context 245a, 255a,
20 265a.
Beneff~ts from the ~ystem
Control structures for recursion and iteration are some of the most flifflrlllt
and error prone aspects of culll~ulel pro~"1"""i"g. Multi-threading is likewise very
~liffir,nlt to incol~ulal~ into programs. By ellcap~ ting these aspects, the
25 proces~ing engine 10 makes the lGII~ tasks of developing a cu~ uL~l procedure
for proces~ing an h~ru~ll-alion flow much simpler than current practice normallyallows. A~ition~lly, by facilit~ting a logical separation of tasks, the use of the
processing engine 10 can result in coll~ule, programs with highly independent,
CA 02228593 1998-03-03
~ WO 97/12339 PCT~US96/14663
-20-
reusable co~ ,oLe..L~. Hence, the ~,oc~ engine 10 can make it easier to ~l~Jeess
iuro~ flows.
rte~ se the ~rucP~ P. engine 10 is very regular and co~ (et it can be r
implem~nt~l in a small and fast co---~ul~lional routine. In ~l~,f.,~l~d embo-1im.snts,
S the L~loces~ engine 10 may be si~ifir~ntly faster than the terllniqlle~c used in the
prior art.
The processing engine 10 is also u ~ al. Typically, several layers of
i. rolmaLion flows must be processed within a co~ ul~l, wl~er~iul upper layers are
logically or physically ~ p~ t~l within the layer below them. Similarly, a
cc,m~ult;r may need to process many i~ ion flows in parallel at the same time.
In each of these cases or even in the combined case, a single in~t~n~e of the frame
processor 12 can be used as a core process, given ~ opLiate adapter and action
routines and lltili7ing standard techniques for task and memory management. Hence
use of the prcces~in_ engine greatly reduce the complexity of information flow
15 proçes~in~ in co~ uLi lg by decreasi g the number of co~ ul~lional co...~o~ L~
involved, providing a com~non a-~;hi~rcl~,.e and single core process for the rem~ining
components, and simplifying each lc~ g component.
The procçcsin~ engine 10 makes it possible to efficiently harness more
complex forms of i. rol..la~ion flow than current practice allows. Rec~u~e the
20 method e.-r~ps..l~t~s recursion, it makes it easy for the full recursive power of
frames to be used in illrollllaLion flows. This in turn adds another ~iim.onSion to the
design of such flows without increasing the ~iiff~ ty of creating procçs~sing routines
to handle them. Thelerole ~lesign~-ns of hlro-lllaLion flows can put more complexity
into their designs because the system can easily be used to process them. For
25 example, the T,.l~ ,.l;onal Standards Or~ ion (ISO) specification of AbstractSyntax Notation 1 (ASN. 1) and the Basic Encoding Rules is an extremely powerfuland efficient protocol which has languished because the protocol is difficult tounderstand and process. The processing engine 10 makes it easier to use this
protocol.
CA 02228593 1998-03-03
- W O 97/1~339 PCT~US96/14663 --
-21-
Exam~le Uses for the System
When a c~ ouu eY~cut~s in a COlu~u~" iLrOl~ iS initia~y
passed to it in various forms from the CUlll~)uL~ e.aL,ll~ system and other sources.
These sources may include, but are not limited to, c~ line ~u~e~lL~,
S e,lvh~ .nent variables, con~lguration files and the results of system calls. By
treating these sources as frames, possibly nested, using adapter luuLilles specific to
each source, the main portion of the cu-~ h.~ prograrn can be inc~ t~l from direct
contact with its o~elaLu,~ e~lvilo-----~L and IL~ ,rul~ be more easily ported bel~
ellvilol~ llLs. In particular, values can be placed on the alLlil~uLe stack at start-up
10 by associating the values with the 'ROOT' frame.
In a complex co.u~ul~r ~C~aliug system ellvhulllllent~ there are normally
many col"~uL~r processes lul~ g prograrns that are eng~ge-l in the task of
co"--..-.~-ir~ting with other c~,."~ across a ~eLwolk. Each program usually deals
with a single type of i~o~ ;cn flow and has unique, often large and complex,
15 procescing routines. An impl~m~ont~tic-n done using the ploces~i..g engine can
combine those programs into a single program run in one process with a single
inct~nre of the procç,ecing engine and multiple sets of (generally sirnpler and smaller)
adapter and action routines. The resllltin~ process ex~cllt~c much faster and the
prûgram is smaller and easier to ..~ than the programs it replaces.
In a n~Lw~lh~d co",l.~.l;i-g ellvil~ nt~ information flows arrive off the
physical neLwolh in low-level encodings of bits which are progressively processed
by different layers of c~l-"l.~ l programs and/or routines By using the procecsing
engine, the layers can be kept distinct (through dirrc.cllt adapter and action l~u~es)
but the overall proces~ing can be simplified, made more compact, and spee~e~l upby incorporating the invention in the proce~in~ core. In pl~r~lled embo-lim~nt~,the COlll~U~l system ù~cldLes 2-3 times faster than directly programmed approaches
used in ~e prior art and is about 20-30 times smaller when combined with an
embodiment which ~cLd~es with the ~eldlillg system.
Some h~olllld~ion flows r~r~sellL information to be displayed on a screen or
to be printed. Special purpose illle~ are typically used to accomplish this
CA 02228593 1998-03-03
W O 97/12339 PCT~US96/14663 --
-22-
rPn-le in~. The in~ ~.l can be used to develop more general ~ ose hlt~
with a common core engine if the i~ ows can be lG~l~,se~t~_d as se~ .r~s
of frames.
Another example is sGcu-iLy e~ y~Lion, where the technique is n~tnr~lly
5 processed in layers. Those layers can be eA~r~,~sed as frames which are easily h~ntlle~l by the procescing engine.
The proc~occing engine 10 is ~.~rliri~ y co,ll~acL that it can be easily
implenn~nt~c~ in haldw~uG or r.lllw~e. This can make the proc~ecin~ engine very
useful for inclusion in any special purpose device that needs to co,n..-....irA~ with
10 other devices, including, but not limited to, ele~;l,oi~ic appliances, m~rhin~ tools and
m.-Aic~ lents. Additionally, such devices can use the procescing engine forprocçs~in~ internal i..ro,l..alion flows. For example, a printer can use the technique
described in the prece~ling paragraph with a ROM-based implement~tion of the
invention.
Detailed Protocol Exam~les
A~endi~ A ~tt~rhr-l hereto is a complete frame processor implenn.-nt~tic-n
for a simple sample protocol. A lexical scal. lel (lexer) breaks the input protocol
into tokens. In this example, the lexer lm-l~rst~n-l~ a parenth~ses-based protocol, an
example of which might look like this: (Fl(al vl)(a2 v2)). This can be read as
'Frame' inct~nre named 'Fl' that has two 'Attributes', 'al' and 'a2', whose values
are 'vl' and 'v2' respectively. Frames can nest, so (Fl(al vl)(F2(a2 vs))(a3 vd)) is
valid (also attributes and frames can be mixed in any order at any level). However,
the lexer does not need to handle hield~ y, it only needs to recognize the tokens
and pass them on to the next procedure.
This example core engine only deals with symbolic tokens passed by the
lexer and not with the protocol itself. Hence the core engine can handle any
protocol that conforms to its senn~ntir model, given a suitable lexer. The only
tokens acceptable to the frame processor are: FRAME_TYPE, END_OF_FRAME,
and ATTRIBUTE. The frame processor forms a hierarchical structure based upon
CA 02228593 1998-03-03
~ W O 97/12339 PCT~US96/14663 -
-23-
the input from the lexer and . ~ .eintPrn~1 data ~Ll-lclulcs (stack and heap) that
co.,l~l;se a scoped symbol table of ~ 1e-value pairs. This enables scoped
inl~ ,re of ~U~ uL~s by nested frames.
The 'action' ~uLilles consist of 'main', which calls the frame processor
S (FREDI) after p~lrc)~ g any ~~Pce-s~.y initi~li7~tion, e.g., setting STDIN andSTDOUT, and has 'ç~llh~r~ ul~s which the frame processor calls at defined
points in protocol proc~Pe~ when a frame is initi~1i7P~1, when a sub-frame is
e,~cuu ~ d, and when the end of a frame is encoullh,l~d. There is a sample
p~tCh table in the code. The callback r~uLi~~s can access attribute values with a
10 'get' routine fhat refurns the ~10~ L1Y scoped value and then do wL~v~-. The
action l~uLilles are completely independent of the details of the input protocol,
in~ te-~ by the frame processor.
The following files are provided in Appendix A:
i) makefile;
ii) fredi.y - bison ~ ~al,
iii) fredi.h;
iv) paren.l - ~alc,.1h~ses protocol lexer;
v) frame.c - sample main, ~ p~trh table, and action louLines
(Two frame types are defined, and they each have three action
~ulilles. The action routines print out the current values of
some attributes); and
vi) test.in - a sample input file (the lexer ignores extra white
space)
Appendix B ~tt~rh~1 hereto is a progr~mming example of what is needed to
attach the frame processor (FREDI) to a real-world protocol. Note that the file
fredi.h provides docnmrnt~tiQn on how to use the frame processor.
Appendix C ~tt~rh~cl hereto is the source version of a binary library that
provides t_e core frame processing engine for the example of Appendix B. The
~tt~rh~1 version of the source code h~n~ s ~ylllllelic attributes including the
- 30 'upAttribute' facility. As provided, the engine is nearly ~~elll.~l~ becallse the static
CA 02228593 1998-03-03
- W O 97/12339 PCTAJS96/14663
-24-
storage re4uhc;lllt; l~ have been ~luced to about 100 bytes. These 100 bytes can be
made part of each context to make the luuli~es 1.
E~uivalents
While this invention has been particularly shown and described with
5 ~c;rc~ ced to ~,~r~.led embo~ x thereof, it will be l-n~lt?rstood by those slcilled
in the art that various changes in form and details may be made therein without
dep~li~l~ from the spirit and scope of the invention as defined by the appended
claims.
These and all other equivalents are intl-nr1etl to be enco~ xse-l by the
10 following claims.
CA 02228593 1998-03-03
WO 97/12339 PCT~US96/14663
-25-
APPF~)IX A
# m~kÇfile for fredi ~ ullles GNU tools: make,gcc?bison,flex
YACC=bison -y
YFLAGS= -d -v
LEX=flex
LOADLIBES= -lfl
fredi: paren.o frame.o
frarne.o fredi.o: fredi.h
paren.l: y.tab.h
y.tab.h: fredi.o
%{
/* fredi.y - FRame EDI core engine version 0.1
#include <stdlib.h>
#include <string.h>
#include "fredi.h"
Sllb~ ~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663
-26-
static void doInilFl~llc(char *pcz);
static void doFinisF-~.c(char *pcz);
static char *getCurrentFrame(void);
static void pushFrarne(char *pcz);
static void popFrame(void);
static void ~ucessAttribute(char ~pc);
static char acAttributes[128*1024];
static char *pcAttribl tecFn-l = acAttributes + sizeof acAttributes;
static struct sFr~meFnt y {
char *pcAttributes;
char aczFrarneType[60];
~ asFr~meFntry[32];
static int iFrarne = 0;
%~
~/Ounion {
char *string;
}
%token <string> FRAME_TYPE
%token cstring> Al~RIBUTE
%token END_OF_FRAME
%type ~string> frarnes frame subframes subfrarne
SIJ~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663
-27-
o~oo/o
r.~...P~ r., ...r.
~ l frames frame
;
frame:FRAME_TYPE {doInitFrame($1);} ~ubfialllcs END_OF_FRAME
~doFinisFrame($ 1 ); }
FRAME_TYPE END_OF_FRAME {initFrarne($1);finisFrarne($1),free($1);}
;
~ubr~.1.,.cs cll~frarne
~ubfi~lles subfrarne
;
~ub~dllle:ATTRIBUTE {processAttribute($1);}
frame
o/o%
yyerror(char *pcz)
int iError= 0;
frarneParseError(iError, pcz);
}
char ~getAttributeValue(char *pcz)
char *pczCurrent = asFr~meFnt~y[iFrarne3.pcAttributes;
S~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/lZ339 PCT~US96/14663
while (pczCurrent < pcAttrib~ltt~cF.n~
if (strcmp(pczCurrent, pcz)) {
pczCurrent += strlen(pczCurrent) + I;
pczCurrent += strlen(pczCurrent) + l;
}
else {
return pczCurrent + strlen(pczCurrent) + 1;
}
}
return NULL;
static void processAttribute(char *pc)
{
int iAttrNameLen = strlen(pc);
int iAttrLen = iAttrNameLen + strlen(pc+iAttrNameLen+l) + 2;
asFr~m~Fntry[iFrame~.pcAttributes -= iAttrLen;
memcpy(asFr~meFntry[iFrame].pcAttributes, pc, iAttrLen);
free(pc);
static void doInitFrame(char *pcz)
char *pczCurrent;
if (pczCurrent = getCurrentFrame()) checkFrame(pczCurrent),
pushFrame(pcz);
SU~S ~ 1 1 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/lZ339 PCTAJS96/14663
-29-
initFrame(pcz);
static void doFinisFrame(char $pCZ)
{
finisFrame(pcz);
popFrameO;
free(pcz);
static char *getCurrentFrame~void)
{
if(iFrame) {
returL asFrameEntry[iFrame].aczFrameType;
asFrameEntry[O].pcA~tributes = pcAttriblltecF,ntl
return NULL;
static void pushFrame(char *pcz)
{
iFl,~llc I l;
asFrameEntry~iFrame] .pcAttributes = asFr~m.oF,ntry[iFrame- 1 ].pcAttributes;
strcpy(asFr~meF.ntry[iFrame].aczFrameType, pcz);
static void popFrame(void)
SUBSTITUTE SHEET (RULE 26)
CA 02228593 1998-03-03
WO 97/12339 PCTAUS96/14663-
-30-
if (iFrame) iFrarne--;
/~ fredi.h */
char *getAttributeValue(char *pcz);
void frameParseError(int iError, char *pczErrorMsg);
void initFrame(char *pcz);
wid checkFrame(char *pcz~;
void finisFrame(char *pcz);
%{
l* paren.l - lexical scanner for a simple par~nth~oses based protocol */
#include "y.tab.h"
#include <stdlib.h>
#include <string.h>
int iParenCount, iWordCount;
char aczAttrName[256];
S~J~ 111 UTE SHEET (RULE 26)
,
-
CA 02228593 1998-03-03
- W O 97/123~9 PCTnUS96/14663 -.
~/o~
~~Os PARSE_SIMPLE_FRAME_TYPE PARSE_FRAME_TYPE PARSE_Al~RIBUTE
WORD ~A-Za-zO-9]+
OPEN PAREN "("
CLOSE_PAREN ")"
WS [\n\t
%%
{WS} {
;
}
cINITIAL>{OPEN_PAREN}{WS}*{WORD}{WS}*{CLOSE_PAREN} {
BEGIN(PARSE_SIMPLE FRAME_TYPE);
yyless(O);
}
<INITIAL>{OPEN_PAREN} {WS} * {WORD} {WS} * {OPEN_PAREN} {
iParenCount = 0;
BEGIN(PARSE_FRAME_TYPE);
yyless(O);
}
<PARSE_FRAME_TYlPE>{OPEN_PAREN} {
if(iParenCount) {
yyless(0);
Sl~..., 1 1 1 UTE SHEET (RULE 26
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663 -
BEGIN(INITIAL~;
}
iParenCount~t;
}
<PARSE_FRAME_TYPE>{WORD} {
yylval.string = strdup(yytext);
return (FRAME_TYPE);
}
<PARSE_SIMPLE_FRAME_TYPE>{WORD} {
yylval.string = strdup(yytext);
BEGIN(INITIAL);
return (FRAME_TYPE);
}
<INITIAL>{OPEN_PAREN}{WS}*{WORD}{WS}+{WORD}{WS}*{CLOSE_PAREN} {
iWordCount = 0;
BEGIN(PARSE_ATTRIBUTE);
yyless(0);
}
<PARSE_SIMPLE_FRAME_TYPE,PARSE_ATTRIBUTE> { OPEN_PAREN} {
.
<PARSE_ATTRIBUTE>{CLOSE_PAREN}
BEGIN(INITIAL);
SIJ~ 1 l l ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCTrUS96/14663
<PAJRSE_ATTRIB UTE>{W ORU~} {
if(iWordCount) {
int iAttrLen = strlen(aczAttrName);
yylv~T ~tnng = malloc(yyleng+iAttrLen+2);
strcpy(yylv~l String, aczAttrNarne);
strcpy(yylval.string+iAttrLen+l, yytext);
yyleng = yyleng + iAttrLen + l;
return (ATTR~BUTE);
}
else {
iWordCount++;
strcpy(aczAttrName, yytext);
}
<INITIAL>{OPEN_PAREN3{WS}*{CLOSE_PAREN} {
;
qNITlAL>{CLOSE_PAREN}
return (END_OF_FRAME);
}
%o~o
SIJtW 1 1 1 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
WO 97/12339 PCT~US96/14663
-34-
/* frarne.c - exarnple action roulil,es for fredi-based protocol pr~ce~
#include <string.h>
#include <stdio.h>
#include "fredi .h"
int F1_init(ch~c~);
int Fl_check(char*pcz);
int Fl_finis(cha~ ;z);
int F2_init(ch~tl,c~);
int F2_check(char*pcz);
int F2_finis(cha~
struct s_fte{
char*aczFrarneType;
int (*pfinit)(char*pcz);
int (*pfCheck)(cha~
int (*pfFinis)(char*pcz);
} as_fte[]={
{"F1", F1_init, Fl_check, F1_finis},
{"F2", F2_init, F2_check, F2_finis)
};
SU~ 1 1 1 UTE SHEET (RULE 2ei)
CA 02228593 1998-03-03
- WO 97/12339 PCTrUS96/14663
#define AS FTE_NUM (si~of as fte / sizeof as fte[O])
void mainO
yy~ O;
printf("Done!\n");
void frameParseError(int iError, char *pczErrorMsg)
printf("Parse error: %d %s\n", iError, pczErrorMsg);
void initFrame(char *pcz)
int iFrame;
if ((iFrame = getFrarneType(pcz)) >= O) (*(as_f~e~iFrame].pffnit))(pcz);
void checkFrame(char *pcz)
int iFrame;
if ((iFrame = getFrameType(pcz)) >= O) (*(as_ftetiFrame].pfCheck))(pcz);
void finisFrame(char *pcz)
S~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTAJS96/14663
-36-
int iFrarne;
if ((iFrarne = getFrarneType(pcz)) >= O) (*(as_fte[iFrame].pfFinis))(pcz);
int Fl_init(char *pcz)
{
printf("Fl init\n");
return O;
int Fl_check(char *pcz)
{
char *pczAttrValue;
printf("F 1_check\n");
if(pczAttrValue = getAttributeValue("al")) printf("al=%s\n",
pczAttrValue);
if (pczAttrValue = getAttributeValue("a2")) printf("a2=%s\n",
pczAttrValue);
return O;
int Fl_finis(char *pcz)
char *pczAttrValue;
printf("F 1_finis\n");
if (pczAttrValue = getAttributeValue("al ")) printf("al =%s\n",
SU~ 111 ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663 _ -
-37-
pczAttrValue);
if (pczAttrValue = getAttributeValue("a2")) printf("a2=%s\n",
pczAttrValue);
return O;
}
int F2_init(char *pcz)
{
printf("F2_init~n");
return O;
}
int F2_check(char *pcz)
{
char ~pczAttrValue;
printf("F2_check\n");
if (pczAttrValue = getAttributeValue("al ")) printf("al =%s\n",
pczAttrValue);
if (pczAttrValue = getAttributeValue("a3")) printf("a3=%s\n",
pczAttrValue);
if (pczAttrValue = getAttributeValue("a4")) printf("a4=%s\n",
pczAttrValue);
return O;
int F2_finis(char *pcz)
char *pczAttrValue;
S~Jb;~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
. WO 97/12339 PCTfUS96/14663 _
-38-
prinff("F2 finis\n");
if(pczAttrValue = getAttributeValue("al")) printf("al=%s\n",
pczAttrValue);
if (pczAttrValue = getAttributeValue("a3 ")) printf("a3 =%s\n",
pczAttrValue);
if (pczAttrValue = getAttributeValue("a4")) printf("a4=%s\n",
pczAttrValue);
return O;
int getFrameType(char *pcz)
{
int i;
for (i=O;i<=AS_FTE_NUM;it~) {
if (strcmp(pcz,as_fte[i].aczFrarneType) = O) return i;
}
return - l;
~FI
(al vl)
(a2 v2)
(F2
(a3 v3)
(a4 v4)
SIJ~ 111 ~ITE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCTAUS96/14663
-39-
)
(F2
(al vll)
~ (a4 v44)
)
(a2 V22)
)
SIJCS~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCT~US96/14663 -
-40-
APP~JX P~
# makefile for Sun using libfredi.a
# sny ANSI C compiler should do
CC- gcc
peb_act: peb_act.o peb_actl.o peb_act2.o peb~en.o peb_lex.o libfredi.a
${CC} -o peb_act peb_act.o peb_actl.o peb_act2.o peb_gen.o peb_lex.o -L.
-Ifredi -11
peb_act.o peb_actl.o peb_act2.o peb_lex.o: fredi.h
peb_act.o peb_actl.o peb_act2.o peb_gen.o: peb_act.h
cIean:
rm -f peb_act *.o core
***~*********************** separator ****************************
Intro
Fredi-based processors have a simple structure that facilitates the partition
of
functions into modules that are them~.olves relatively simple, hopefully
decl~,asing
SUI~;~ 111 UTE SHEET (RULE 26)
-
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663
41-
the overall complexity of building and mA;--Ih;-~ complex protocol
~c~ c~;"~
pro~r~m~
Fredi views all input as a b~l~nre~l recursive set of 'frames' and mQ;. .~ a
scoped
symbol table to support proces~ing them. Frames have any number of attributes
which
themselves can be frames. Fredi on}y deals in 'abstract' syntax; the
prograrnmer provides
t~he translation to and from the ~ sr~ .~ syntax used 'on the wire'. The
programmer
also provides the sem~ntic proct-scinp
The standard fredi routines are enr~psul~ted as a library of functions that
require
certain 'callbacli' routines to be provided by the programrner. Thus the fredi
routines
can be viewed as 'middleware'.
Specifically, the programmer must create:
. A main routine that sets stdin, stdout & stderr and calls entry point
YY~ ,eO
. A 'lexer' routine with entry point yylex() that tc-keni7~s the input into:
- FRAME_TYPE (start of frame)
- ATTRIBUTE (a scalar attribute/value pair)
- END_OF_FRAME
- CHECKPOINT (used to establish a known and recoverable fredi symbol table
state)
S~J~;j 111 ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97~12339 PCTAUS96/14663
-42-
. Action 1~ u~ es to be called by fredi when frarnes start and finish
p.oce~s.t.g and
when parse errors occur. Typically the prog.~ also creates a
'g.,.lC.dlOl' routine
as well to output the LL~ISI-1 syntax based upon the ~kstr~ct syntax and
s~om~ntics~
I he pro~r~mmer gets from fredi:
. Routines to 'put' frames and attributes from the lexer.
. Routines to 'set' attributes from action routines.
. A Routine to 'get' the current frame from action routines.
. Routines to 'get' attributes from action .oulil.es.
. Miscellaneous other useful routines.
. Define's for fredi data types - only a few currently...
*/
/* API's implementerl by action routines for the FREDI support routines */
void frParseErr(int iErr, char *pczErrMsg);
/~ iErr is always O cu..c:.llly~ pczErrMsg is whatever comes from yyparse()
*/
void frChlcFrm(char *pczFrmType, char *pczSubFrmType);
1~
Called when a new frame is encountered; pczFrameType is the current
(enclosing)
SlJ~ 111 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97/12339 PCTAUS96/14663
43-
frame type, pczSubFrmType is the new frame type, frame level is at the
current
(~n~losin~) frame.
~ I
void frInitFrm(char *pczSubFrmType, char *pczFrmType);
/*
Called after frChlcFrmwhen a new frame is encountered; pczSubFrmType is
the
current (new) frame type, pczFrameType is the enclosing frame type,frame
level
is at the current (new) frame - no attributes will have been set.
*/
void frFinFrm(char *pczFrmType);
I*
Called when the end of a frame is encountered, pczFrmType is the current
frame
type, frame level is at the current frame. All frame attributes are
available
and will be 'popped' out of fredi's symbol table when this call returns.
*/
/* API's implem~nt~cl by the FREDI support routines for action routines */
/*
Note: fredi implements simple versions of some routines when only 'string'
versions of attributes are of interest. However, fredi can handle
SU~ 111 IJTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663
~4-
values up to about 8K (cu~ y)~ fredi can handle a pointer as the value
of
an attribute, so BLOBs should be passed ~ ~.oi~ . Future versions of
fredi will do 'garbage collection' on such point~, but Cu~ lly the
progr~n mPr is le~ol.~ible for deallocating memory.
*l
l*
Get: fredi has scoped memory and will 'get' the most tightly scoped
attribute
value. The 'get next' routines walk through all attribute values in scoped
order.
*/
char *frGetAttrVal(char *pczAttrNm);
I*
Returns a pointer to a copy of the string value of the attribute whose
name is pointed to by pczAttrNm.
*l
char *frGetAttrValBin (
char *pczAttrNm, /*in*/
void *pvAttrValBin, /*out - pointer to Ivalue allocated by caller */
int *piAttrValType,
int *piAttrValBinLen,
int *piAttrStat
);
I*
Returns a pointer to a copy of the string value of the attribute whose
SlJ~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663 -
15-
name is pointed to by pczAttrNm. Also copies the binary value of the
attribute
(if present) to *pvAttrValBin if pvAttrValBin is not NIJLL.
/
int frSetAttr(char *pczAttrNm, char *pczAttrValStr);
~*
Copies the value pointed to by pczAttrValStr to the string value of the
attribute whose name is pointed to by pczAttrNm. Returns O always (for
now).
*l
int frSetAttrBin (
char *pczAttrNm,
char *pczAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat
);
/*
Copies the value pointed to by pczAttrValStr to the string value of the
attribute whose narne is pointed to by pczAttrNm. If pvAttrValBin is not
NULL,
copies iAttrValBinLen bytes of the value pointed to by pvAttrValBin to
the
binary value of the attribute. Returns O always (for now).
*l
Sl,~S 1 1 1 ulTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCT~US9G/14663
16-
int frUpAttr(char *pczAttrNm, char *pczAttrValStr);
I*
ntir~l to the 'set' routine but positionr~ the attribute in the scope
of the
~ -qnr~ iin~' frarne. This a very usefill and general way of'~
values
from a frame, i.e. resolving frames into scalars. The l~,Lu~l~cd values
can be
used to control processing in the enclosing frame or prop~t~ to
higher levels.
~/
int frUpAttrBin (
char *pczAttrNm,
char *pczAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat
);
I* See above */
int frGetNxtAttr (
int *piFrmLvl,
char **ppczFrmType,
char **ppczAttrNm,
char **ppczAttrValStr
);
I*
S~S 1 1 1 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 _
-47-
Returns the 'next' attribute and infc ....nl;~n about the frame to which it
b~lon~
Sets poilllel~ to copies ofthe relevant strings. Returns O nnr~n~lly;
returns - 1
on the call ~ubse~luellito the call in which the last attribute was
If any input ~ ~ter is NULL, no attempt is made to retrn a value
for that pararneter.
*/
int frGetNxtAttrBin (
int *piFrmLvl,
char **ppczFrmType,
char **ppczAttrNm,
char **ppczAttrValStr,
void **ppvAttrValBin,
int *piAttrValType,
int *piAttrValBinLen,
int *piAttrStat
);
/*
Retums the 'next' attribute and inforrn~tion about the frarne to which it
belongs.
Sets pointers to copies of the relevant values and updates integers.
Retums O
normally; returns -1 on the call subsequent to the call in which the
last attribute
was ret~rnP~l If any input parameter is NULL, no attempt is made to
retrn a value
Sl,~ 1 1 1 UTE SHEET (RULE 26
CA 02228593 1998-03-03
W O 97/12339 PCT~US96/14663
48-
for that p~dl~e.t~,..
*l
int frGetNxtAttrReset(void);
/*
Resets the 'attribute walk' such that the next call to a 'get next'
routine
retrieves the first one. Called autom~tir~lly when a 'get next' routine
returns - 1
or when the end of a frame is reached. Always returns 0 (~ tly).
*~
char *frGetFrm (
void **ppvUsrHndl,
int *piOffStrt,
int *piOffNxt
);
/* Returns the current frarne type and its information - see below. */
Note: there may be a 'walk' function added for frames in the future
analogous to
the attribuute walk and posssibly a 'set' function.
*/
int frSkipFrm(void);
I*
Causes fredi to skip to the end of the frarne, including skipping all
SU~ UTE SHEET (RULE 26~
CA 02228593 1998-03-03
WO 97/12339 PCT~US96/14663
-49-
frarnes. The end of frame routine will be called for the frame. Allows
the ~ ... r ~
to 'bail out' if things go bad, e.g. ~l~t~k~ce failure, and may have
other uses...
*l
/* API's implem~nt~-~l by the FREDI support routines for lexer */
int frPutFrm (
char *pczFrmType,
void *pvUsrHndl,
int iOff~;trt,
int iOffNxt
~;
I*
Pl~pdl~;s a new frame. Copies the frame type from the string pointed to
by pczFrmType.
Stores the other vahles, regardless of contents. Contemplated uses
include identifying
the starting and next offsets of the raw input in a file or buffer such
that a
raw frame including its contents can be sent lla~ enlly somewhere
else. Always
returns 0 (-;ull~ n~ly). The frarne is not 'co.... ~ cl' until the lexer
returns with
FRAME_TYPE.
*l
S~J~ 111 ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
-' W O 97/12339 PCTAUS96/14663
-50-
int frUpdtFrm (
void *pvUsrHndl,
int iOffStrt,
int iOffNxt
);
/*
Updates values in the current frarne. C~ontPmrl~tp~l to be called when end
of frame is
reached in order to update values. If any of the integer & ..~ is
setto-l before
the call, or if pvsrHndl is set to NULL, then that value is not llp~l~te~l
*/
int frPutAttr(char *pczAttrNm, char *pczAttrValStr);
/* F'l~ ~,s a new attribute in the current frame. Analogous to 'set
attribute' above. */
int frPutAttrBin (
char *pczAttrNm,
char *pczAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrV~lRinT Pn,
int iAttrStat
);
I* see above */
/* values shared by all */
SUBSTITUTE SHEET (RULE 26)
.
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663
enum eAttrValType {FR STR TYPE, FR_BIN_TYPE};
/* values for co" ,. "~ iç~tin~ from the lexer to the fredi core engine *l
#ifndef YYSTYPE
#define YYSTYPE int
#endif
i~define FRAME TYPE 258
#define ATTRIBUTE 259
#define END OF FRAME 260
~define CHECKPOINT 261
extem YYSTYPE yylval;
******~******************** sepa~aLor ****************************
/* peb_act.h - prototypes for action routines */
int root check(char *pczFrarneType, char *pczSubFrarneType);
int default_finis(char *pczSubFrameType);
int RE~AU1 init(char *pczSubFrarneType, char *pczFrarneType);
int RE~AUl_check(char *pczFrameType, char *pczSubFrarneType);
int REQ~AU1 finis(char *pczSubFrameType);
void sendFrarneType(char *pczFrameType);
void sendAttribute(char *pczAttrName, char *pczAttrValue);
void sen-lFn-lOfFrarne(void);
void s~n~Fn-lOfContent(void);
***************************~e~uaL~l************************~***
S~J~ ITE SHEET ~RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCT~US96/14663 - -
/* peb act.c ~ lplc action rou~ es for fredi-based protocol pr~ceccin~
*l
/* using the Pebble protocol
*/
#include "peb_act.h"
int yy~e(void);
void main()
yyparse();
s~qnllFn~lOf~ontent();
*************************** separator ****************************
I* peb_actl.c - exarnple action routines for fredi-based protocol processing
*/
/* using the Pebble protocol
*l
#include ~string.h>
#include <stdio.h>
#include "fredi.h"
#include "peb act.h"
static int getFrameType(char *pczFrameType),
static struct s_fte {
SUe~ UTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTAJS96/14663 _ '
char *a.,~FlalllcType;
int (*pffnit)(char *pczSubFrameType, char *pczFrameType);
int (*pfCheck)(char ~c~F~,.cType, char *pczSubFrameType);
int (*pfFinis)(char *pczSubFrarneType);
as_fte[l= {
{"default", NULL, NULL, default_finis},
{"root", NULL, root_check, NIJLL},
{"REQ/AUI", REQAUl_init, REQAUl_check, REQAUl_finis}
~;
#define AS_FTE_NUM (sizeof as_fte / sizeof as_fte[O])
void frParseErr(int iErr, char *pczErrMsg)
{
fprintf(stderr, "Parse error: %d %s\n", iErr, pczErrMsg);
void frInitFrm(char *pczSubFrameType, char *pczFrameType)
{
int iFrarne;
if (as_fte[iFrarne = getFrameType(pczSubFrarneType)].pffnit)
(*(as_fte[iFrarne].pfInit))(pczSubFrarneType, pczFrarneType);
void frChkFrrn(char *pczFrarneType, char *pczSubFrarneType)
{
int iFrarne;
SUtlSi 111 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97/12339 PCT~US96/14663.
-~4-
if (as_fteriFrarne = getFrameType(pczFrameType)].pfCheck)
(*(as fte[iFrarne].pfCheck))(~c~ cType, pczSubFrarneType);
void frFinFrrn(char *pczFrarneType)
int iFrame;
if (as_fte[iFrarne = getFrarneType(pczFrameType)].pfFinis)
(*(as_fte[iFrarne] .pfFinis))(pczFrameType);
static int getFrarneType(char *pczFrarneType)
{
int i;
for(i=I;i<AS_FTE_NUM,i~) ~
if (strcmp(pczFrarneType,as_fte~i].aczFrarneType) = O) return i;
}
return O;
*************************** S~,palalOr **************************** ....
/* peb_act2.c - exarnple action .~ i..es for fredi-based protocol procescing
*~
/* using the Pebble protocol
*/
SU~3 111 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97112339 PCTAUS96/14663 _ -
#incIude <sh;n~h>
#include Cstdio.h>
~include "fredi.h"
#include "peb_act.h"
int root_check(char *pczFrameType, char *pczSubFrameType)
if(pczSubFrameType[O] !='R') {
frSkipFrm();
fprintf(stderr, "%s cannot contain %s\n", pczFrameType, pczSubFrameType);
return O;
}
int default_finis(char ~"pczFrameType)
{
char *pczAttrValue;
char *pczFrameTypeTemp;
int iFrameLevel;
char *pczAttrName;
fprintf(stderr, "Unrecognized Frame Type:%s\n", pczFrameType);
while(!frGetNxtAttr(&~iFrameLevel,&pczFrameTypeTemp,&pczAttrNarne,&pczAttrValue))
{
fprintf (
SlJ~a 1 l l ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663 -
-56-
stderr,
" Fr~m~oT.evel=%d; FrameTy~ .,s; AttrName=%s; AttrValue=%s\n",
iFr~mPT.evel,
pczFrameTypeTemp,
pczAttrName,
pczAttrValue
~;
}
return O;
}
int REQAUl_init(char *pczSubFrameType, char *pczFrameType)
if (strcmp(pczFrarneType, "root")) {
frSkipFrrn();
fprintf(stderr, "%s cannot be cont~in~cl in %s\n", pczSubFrarneType,
pczFrameType);
return O;
}
fprintf(stderr, "Frame Type:%s\n", pczSubFrameType);
return O;
}
int REQAUl_checlc(char ~pczFrarneType, char *pczSubFrarneType)
{
frSkipFrm();
fprintf(stderr, "%s cannot contain %s\n", pczFrarneType, pczSubFrameType),
SIJ~ 1 l l ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/1Z339 PCTrUS96/14663 _ :
-57-
return O;
int RE~AUl_finis(char ~c~Fl~.lcType)
{
char *apczAttrNarne[l = ~
"AID","ATP","CID","TDT" ,"TID","TOT","VID","AXD","CDM","TTM"
};
int iAttrNames = sizeof(apczAttrName) / sizeof(apczAttrNarne[0]);
inti;
char *pczAttrValue;
for (i=0;i<iAttrNarnes;it~) ~
if ((pczAttrValue = frGetAttrVal(apczAttrName[i])))
fprintf(stderr, " %s:%s\n", apczAttrNarne[i], pczAttrValue);
sendFrarneType("RSP/RSP");
sendAttribute("RES"," 1 ");
sendAttribute("REF","2");
sendAttribute("TID","3");
sendAttribute("MSG","Simnl~t~-cl Failure...");
s~nrlF.n~10fFrarneO;
return 0;
- *************************** sep~Lor ****************************
/* peb_gen.c - example generator routines for fredi-based protocol processing
SUBSTITUTE SHEET (RULE 26)
CA 02228593 1998-03-03
WO 97/12339 PCT~US96114663
-58-
*~
/* using the Pebble protocol
*l
~u~cludc <string.h>
Xinclude <stdio.h>
~include "peb_act.h"
void sendFrameType(char *pczFrameType)
{
if (strcmp(pczFrarneType, "RSP/RSP")) {
pczFrameType[3] = ':';
printf~"%s\t", pczFrameType);
else {
printf~"RSP:");
void sendAttribute(char *pczAttrName, char *pczAttrValue)
if(strcmp(pczAttrNarne,"RES")) {
printf("%s:%s\t", pczAttrName, pczAttrValue);
}
else {
printf~"%s\t", pczAttrValue);
SUe~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663
-58/1-
void s~n~lFn-lOfFrame(void)
{
printf("\n");
}
void s~n.lFn~lOf~on~t(void)
{
printf~"\f");
***************************Set)~alOl****************************
%~
I* simple pebble lexer "'/
#include 'stdio.h>
#include <string.h>
#include "fredi.h"
char aczAttrName[128];
char aczFrameType[128];
char aczAttr[128~;
%}
%s SCAN_ALL GET_NAME DO_RSP_FRAME_TYPE DO_~RAME_TYPE
DO_ATrRIBUTE CLEANUP
-
~JS t ]
SU~;i ~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTAUS96/14663
-58/2-
ATTR_SEP [:]
ATTR_END \t
LINE_END \n
CONTENT_END \f
NAME [A-y+
VALUE r \t\n\f~+([ ]+[~ \t\n\fl+)*
%%
{WS} {
;
}
<INITIAL>. {
yyless(0);
BEGIN(SCAN_ALL);
<SCAN_ALL>{CONTENT_END} {
return(0);
}
<SCAN_ALL>{LINE_END} {
return(END_OF_FRAME);
<SCAN_ALL>{NAME} ~ATTR_SEP} {WS}*{VALUE} {WS}*~ATTR_END}
y~less(0);
BEGIN (GET_NAME);
Sl~ l l ulTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCT~US96/14663
-58/3-
}
<GET_NAME>{NAME}{ATTR_SEP} {
if ((strcmp("RSP:", yytext) = O)) ~
BEGIN(DO RSP_FRAME_TYPE);
else ~f (
(strcmp ("REQ:", yytext) = O)
Il (strcmp("CTX:", yytext) = O)
){
strcpy(aczFrameType, yytext);
aczFrameType[yyleng-1] = 0;
BEGIN(DO_FRAME_TYPE);
else {
strcpy(aczAttrName, yytext);
aczAttrName[yyleng-1] = 0;
BEGIN(DO_ATTRIBUTE),
}
CDO_ATTRlBuTE>{vALuE} {
frPutAttr(aczAttrName, yytext);
BEGIN(CLEANUP);
return(ArrRIBUTE);
<DO_RSP_FRAME_TYPE>{VALUE} {
int i;
SIJ~S~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/lZ339 PCT~US96/14663
-58t4-
frPutFrrn("RSP/RSP", NULL, O, O);
strcpy(aczAttr, "RES:");
strcat(aczAttr, yytext);
for (i=strlen(aczAttr)-l ;i>=O;i--) unput(aczAttr[i]);
BEGIN(SCAN_ALL);
return(FRAME_TYPE);
<DO_FRAME_TYPE>{VALUE} {
strcat(aczFrarneType,"/");
frPutFrrn(strcat(aczFrameType,yytext), NULL, O, O);
BEGIN(CLEANUP);
return(FRAME_TYPE);
<CLEANUP> {ATTR_END } {
BEGIN(SCAN_ALL);
}
%%
int yyw~ (void)
return l;
}
**s~ dt~JI****************************
The following lines are sample input of the Pebble protocol:
REQ:AUI AID:aid_string ATP:atp_const
Slutsa ~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCT~US96/14663
-58/5-
CID:cid_string TDT:tdt_date TID:tid_num TOT:tot_rnoney
VID:vid_string AXD:axd_date CDM:cdm_string TTM:ttm_time
REQ:AUl AID:2aid_string ATP:atp_const
CID:cid_string TDT:tdt_date TID:tid_nurn TOT:tot_money
VID:vid_string AXD:axd_date CDM:cdm_string TTM:ttm_time
SU~ ~ ITE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCTnUS96/14663 -
-58/6-
St;~ At~********************
The following lines are sample output of the Pebble protocol,
these lines are gener~te(l by the action routines and are
elves process~hle as input:
RSP:I REF:2 TID:3 MSG:Sim~ t~o~1 Failure...
RSP:l REF:2 TID:3 MSG:Sim~ te~ Failure...
SU~;~ JTE SHEET (RULE 26
CA 02228593 1998-03-03
W O 97112339 PCTAUS96/14663
-58~7-
APPF,NnJX C
I* fr spt.h - FRame EDI core engine version 0.3 */
I* API's imr.le. ~ by FREDI support lcJulill. s (fr_spt.c) for the FREDI core
*l
void frDoAttr(void);
void frDoInitFrrn(void);
void frDoFinFrm(void);
void frDoChkPt(void);
***"********sep~r~t-r************************,"***
%{
I* fr~rarn.y - FRame EDI core engine version 0.3 */
#include "fr_spt.h"
%}
%token FRAME_TYPE ATTRIBUTE END_OF_FRAME CHECKPOINT
%o/o
frameList: frameList frame I frame;
frarne: FRAME_TYPE {frDoInitFrmO;} subFrameT i~t END_OF_FRAME {frDoFinFrrnO;}
FRAME_TYPE END_OF_FRAME {frDoInitFrm0;frDoFinFrm0;}
SIJ~S 111 ~ITE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663
-58/8-
I CHECKPOINT {frDoChkPtO;}
subFr~m~T i~t subFr~mer i~t subFrarne I subFrame
subF~ame: ATTRIBUIE {frDoAttrO;} I frame;
o/oo~o
******************s~lur******~*********************
/* fr spt.c - FRame EDI core engine version 0.3 */
~include <stdlib.h>
#include cstdio.h>
t~include <string.h>
~include "fredi.h"
~include "fr_spt.h"
typedef struct s.AttrFntStruct *psAttrEnt;
typedef struct sFrmFnt~truct *psFrmEnt;
typedef struct sAttrFnt~truct ~
psAttrEnt psAttrEntNxt; -
psFrrnEnt psFrmEntOwn;
char *pczAttrValStr;
char $pczAttrValStrCpy;
void *pvAttrValBin;
void *pvAttrValBinCpy;
int iAttrValType;
Slu~;~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97/12339 PCTrUS96/14663
-58/9-
int iAttrValBinLen;
int iAttrStat;
~ sAttrEnt;
static psAttrEnt psAttrEntTail = NULL;
static psAttrEnt psAttrEntNew = NULL;
static psAttrEnt psAttrEntWalk = NULL;
typedef struct sFnnF.nt!;~truct {
psFrrnEnt psFrrnEntNxt;
psAttrEnt psAttrEntHead;
psAttrEnt psAttrEntTail;
int iFrrnLvl;
void *pvUsrHndl;
int iOf~Strt;
int iOffNxt;
} sFrmEnt;
static struct sFrmRootStruct {
sFrmEnt sFrmEntRoot;
char aczRoot[~64 - sizeof(sFrrnEnt))];
} sFrmRoot = { {NULL, NULL, NULL, 0, NULL, 0, 0}, "root" };
static psFrmEnt psFrrnEntTail = &sFrmRoot.sFrmEntRoot;
static psFrrnEnt psFrmEntNew = NULL;
static psFrmEnt psFrmEntFree = NULL;
static int iSkip = 0;
static int iChlcPtNum = 0;
SlJ~ 1 1 1 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
_ W O 97/12339 PCTAUS96/14663
-58/lO-
statie int frDoPutAttrBin (
ehar *pezAttrNm,
ehar *pezAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat,
psAttrEnt *ppsAttrEnt
);
static char *frGetFrmType(psFrmEnt psFrmEntTmp);
statie char *frGetAttrNm(psAttrEnt psAttrEntTmp);
int yyerror(char *pcz)
{
int iErr= O;
frParseErr(iErr, pez);
return O;
}
int frSkipFrm(void)
{
if (!iSkip) iSkip = 1;
return O;
int frUpAttr(ehar *pczAttrNm, char *pezAttrValStr)
{
Sl,..S 111 ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97/12339 PCTAUS96/14663 _ -
-58/11-
void *pvAtkvalBin = NULL;
int iAttrValType = FR_STR_TYPE;
int iAttrValBinLen = O;
int iAttrStat= O;
return frUpAttrBin (
pczAttrNm,
pczAttrValSk,
pvAttrValBin,
iAttrValType,
iAttrValBinLen,
iAtkStat
);
int frUpAttrBin (
char *pczAtkNm,
char *pczAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat
)
{
psAttrEnt psAttrEntUpNew;
int iRetum;
~ if ((iRetum = frDoputAtkBin (
pczAttrNm,
SlJb~ ~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663
-58/12-
pczAttrValStr,
pvAttrValBin,
iAttrValType,
iAttrV~1RinT .-on,
iAttrStat,
&psA tt~F-ntUpNew
)
)){
return iReturn;
}
ps~t~rF.ntUpNew->psAttrEntNxt = psFrmEntTail->psFrmEntNxt-~psAttrEntTail;
psAttrEntUpNew->psF~nEntOwn = psFrmEntTail->psFrmEntNxt;
psFrrnEntTail->psFrmEntNxt->psAttrEntTail = psAttrEntUpNew;
if (psFrmEntTail->psAttrEntHead) {
psFrmEntTail->psAttrEntHead->psAttrEntNxt = psAttrEntUpNew;
}
else {
psAttrEntTail = psAttrEntUpNew;
}
if (!psFrmEntTail->psFrmEntNxt->psAttrFn~e~
psFrmEntTail->psFrmEntNxt->psAttrEntHead = psAttrEntUpNew;
return 0;
int frSetAttr(char *pczAttrNm, char *pczAttrValStr)
SUBSTITUTE ''I .__ I (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTrUS96/14663
-58/13-
void *pvAttrValBin = NULL;
int iAttrValType = FR_STR TYPE;
int iAttrValBinLen = O;
int iAttrStat = O;
return frSetAttrBin (
pczAttrNm,
pczAttrValStr,
pvAttrValBin,
iAnrValType,
iAttrValBinLen,
iAttrStat
);
int frSetAttrBin (
char *pczAttrNm,
char *pczAnrvalstr~
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat
)
psAttrEnt psAttrEntTmp;
int iReturn;
if ((iReturn = frDoPutAttrBin (
SU~ l UTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTAJS96/14663 _ -
-58/14-
pczAttrNm,
pczAttrValStr,
pvAttrValBin,
iAttrValType,
iAttrValBinLen,
iAttrStat,
&psAttrEntTmp
)
~ )){
return iReturn;
}
psFrmEntTail->psAttrEntTail = psAttrEntTmp;
psAttrEntTmp->psFrmEntOwn = psFrmEntTail;
psAttrEntTmp->psAttrEntNxt = psAttrEntTail;
psAttrEntTail = psAttrEntTmp;
return 0;
}
int frPutAttr~char *pczAttrNm, char *pczAttrValStr)
void *pvAttrValBin = NULL;
int iAttrValType = FR_STR_TYPE;
int iAttrValBinLen = 0,
int iAttrStat = 0;
return frPutAttrBin (
pczAttrNm,
pczAttrValStr,
Slu~;~ 111 IJTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97112339 PCT~US96/14663
-58/15-
pvAttrValBin,
iAttrValType,
iAttrValBinLen,
iAttrStat
);
}
int frPutAttrBin (
char *pczAttrNm,
char *pczAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat
)
{
if (iSkip) retum O;
if (psAttrEntNew) free(psAttrEntNew);
retum frDoPutAttrBin (
pczAttrNm,
pczAttrValStr,
pvAttrValBin,
iAttrValType,
iAttrValBinLen,
iAttrStat,
&psAttrEntNew
);
S~Jts~ 111 ~ITE SHEET (RULE 26
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 _ -
-58/16-
int frDoPutAttrBin (
char *pczAttrNm,
char *pczAttrValStr,
void *pvAttrValBin,
int iAttrValType,
int iAttrValBinLen,
int iAttrStat,
psAttrEnt *ppsAttrEnt
)
{
psAttrEnt psAttrEntTmp;
int iAttrNmLen = strlen(pczAttrNm);
int iAttrValStrLen = strlen(pczAttrValStr);
int iAttrValStrOff;
int iMalloc;
iAttrValStrOff= iMalloc = sizeof(sAttrEnt~ + 2*(iAttrNmLen+l);
if(pczAttrValStr) iMalloc += 2*(iAttrValStrLen+l);
psAttrEntTmp = malloc(iMalloc);
."- .,,c~t(psAttrEntTmp~ 0, iMalloc);
strcpy((char *)psAttrEntTmp + sizeof(sAttrEnt), pczAttrNm);
if(pczAttrValStr) ~
psAttrEntTmp->pczAttrValStr = (char *)psAttrEntTmp + iAttrValStrOff;
strcpy(psAttrEntTmp->pczAttrValStr, pczAttrValStr);
psAttrEntTmp->pczAttrValStrCpy = psAttrEntTmp-~pczAttrValStr +
iAttrValStrLen + l;
}
SlJt~ 111 ~JTE SHEET ~RULE 26)
CA 02228593 1998-03-03
- W O 97/lZ339 PCTnUS96/14fi63
-58/17-
if (pvAttrValBin && ~iAttrValBinLen >= O)) {
psAttrEntTmp->pvA.ttrValBin = malloc(iAttrv~lRinT en + I);
memcpy(psAttrEntTmp->pvAttrValBin, pvAttrValBin, iAttrV~lRinT ~n);
psAttrEntTmp->iAttrValBinLen = iAttrValBinLen;
*((char ~)psAttrEntTmp->pvAttrValBin + iAttrValBinLen) = O;
psAttrEntTmp->pvAttrValBinCpy = malloc(iAttrValBinLen + l);
psAttrEntTmp->iAttrValType = iAttrValType;
psAttrEntTmp->iAttrStat = iAttrStat;
*ppsAttrEnt = psAttrEntTmp;
return O;
void frDoAttr(void)
{
if (!psAttrEntNew) rehlrn;
if (iSkip) return;
if (!psFrmEntTail->psAttrEntHead)
psFrmEntTail->psAttrEntHead = psAttrEntNew;
psAttrEntNew->psAttrEntNxt = psAttrEntTail;
psFrmEntTail->psAttrEntTail = psAttrEntNew;
psAttrEntNew->psFrmEntOwn = psFrmEntTail;
psAttrEntTail = psAttrEntNew;
psAttrEntNew = NULL;
5~ 1 UTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCTrUS96/14663 -
-58/18-
char *frGetAttrVal(char *pczAttrNm)
{
return frGetAttrValBin (
pczAttrNm,
NULL,
NULL,
NULL,
NULL
);
char *frGetAttrValBin (
char *pczAttrNm, I*in*/
void *pvAttrValBin, /*out - pointer to Ivalue allocated by caller or NULL
*/
int *piAttrValType,
int *piAttrValBinLen,
int *piAttrStat
)
{
psAttrEnt psAttrEntNxt = psAttrEntTail;
char *pczAttrValStrCpy = NULL;
while (psAttrEntNxt) ~
if (strcmp(pczAttrNm, (char *)psAttrEntNxt + sizeof(sAttrEnt))) {
psAttrEntNxt = psAttrEntNxt->psAttrEntNxt;
else ~
if (piAttrValType) *piAttrValType = psAttrEntNxt-~iAttrValType;
S~J~ 111 ~JTE SHEET (RULE 26)
_
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663 _ -
-58/19-
if (piAttrValBinLen) *piAttrValBinLen = psAttrEntNxt->iAttrValBinLen;
if (piAttrStat) ~piAttrStat = psAttrEntNxt->iAttrStat;
if (psAttrEntNxt-~pczAttrValStr)
pczAttrValStrCpy = strepy(psAttrEntNxt->pczAttrValStrCpy,
psAttrEntNxt->pczAttrValStr);
if (pvAttrValBin && psAttrEntNxt->pvAttrValBin)
memcpy(pvAttrVa~Bin, psAttrEntNxt-~pvAttrValBin,
psAttrEntNxt->iAttrValBinLen + l);
return pczAttrValStrCpy;
}
};
*piAttrValType = O;
*piAttrValBinLen = O;
*piAttrStat = O;
retum NULI_;
}
int frGetNxtAttr (
int *piFrmLvl,
char **ppczFrmType,
char **ppczAttrNm,
char **ppezAttrValStr
)
{
retum frGetNxtAttrBin (
SlJ~_ 1 l l UTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663
-58/20-
piFrmLvl,
~ Type,
ppczAttrNr4
ppczAttrValStr,
NULL,
NULL,
NULL,
NULL
);
}
int frGetNxtAttrBin (
int *piFrrnLvl,
char ~p~ FrmType,
char **ppczAttrNm,
char **ppczAttrValStr,
void **ppvAttrValBin,
int *piAttrValType,
int *piAttrValBinLen,
int *piAttrStat
)
psAttrEnt psAttrEntTmp;
if (psAttrEntWaLk = (psAttrEnt)(- 1 )) {
psAttrEntWalk = NULL;
if (piFrmLvl) *piFrmLvl = O;
if (ppczFrmType) *ppczFrmType = NULL;
if (ppczAttrNm) *ppczAttrNm = NULL;
S~J~ 111 ~JTE SHEET (RULE 26
CA 02228593 1998-03-03
. W O 97/12339 PCT~US96/14663
-58/21-
if (ppczAttrValStr) *ppczAttrValStr = NIJLL;
if (ppvAttrValBin) *ppvAt~ValBin = NULL;
if (piAttrValType) *pLAttrValType = 0;
if (piAttrValBinLen) *piAttrValBinLen = 0;
if (piAttrStat) *piAttrStat = 0;
return -1;
}
if (!psAttrEntWalk) psAttrEntWalk = psAttrEntTail;
if (piFrrnLvl) *piFnmLvl = psAttrEntWaLk->psFnnEntOwn->iFnnLvl;
if (ppczFrmType) ~p.;~ l-Type = frGetFrmType(psAttrEntWalk->psFnnEntOwn);
if (ppczAttrNm) *ppczAttrNm = frGetAttrNm(psAttrEntWalk);
if (ppczAttrValStr && psAttrEntWalk->pczAttrValStr)
*ppczAttrValStr= strcpy(psAttrEntWalk->pczAttrValStrCpy,
psAttrEntWalk->pczAttrValStr);
if (ppvAttrValBin && psAttrEntWalk->pvAffrValBin)
*ppvAttrValBin = memcpy (
psAffrEntWalk->pvAttrValBinCpy,
psAttrEntWalk->pvAttrValBin,
psAffrEntWalk->iAffrValBinLen
);
}
if (piAffrValType) *piAttrValType = psAttrEntWalk-~iAttrValType;
if (piAttrValBinLen) *piAttrValB inLen = psAttrEntWalk-~iAttrValB inLen;
if (piAttrStat) *piAttrStat--psAffrEntWalk->iAttrStat;
SIJ~ 111 ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
W O 97/12339 PCT~US96/14663
-58/22-
psAttrEntTmp = psAttrEntWalk;
psAttrEntWalk = psAttrEntWalk->psAttrEntNxt;
if (!psAttrEntWalk) psAttrEntWalk = (psAttrEnt)(-l);
return 0;
}
int frGetNxtAttrReset(void)
{
psAttrEntWalk = NULL;
return 0;
}
int frPutFrm (
char *pczFrmType,
void *pvUsrHndl,
int iOffStrt,
int iOffNxt
)
{
int iFrmTypeLen;
if (iSkip) return 0;
if (psFrmEntNew) free(psFrmEntNew);
iFrmTypeLen = strlen(pczFrmType);
if (psFrrnEntFree) {
if (strcmp((char *)psFrmEntFree + si~of(sFrmEnt), pczFrmType)) {
psFrmEntNew= realloc(psFrrnEntFree, si~of(sFrmEnt) +
2*(iFrmTypeLen+l));
SUI~ 111 ~JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCTnUS96/14663
-58/23-
strcpy((char *)psFrmEntNew + si~of(sFrmEnt), pczFrmType);
else {
psFrrnEntNew = psFlmEntFree;
}
psFrmEntFree = NULL;
~ else ~
psFrmEntNew= rnalloc(sizeof(sFrrnEnt) + 2*(iFrrnTypeLen+l));
psFrmEntNew->psFrmEntNxt = NIJLL;
psFrrnEntNew->iFrmLvl = - l;
psFrmEntNew->psAttrEntHead = NULL;
psFrrnEntNew->psAttrEntTail = NULL;
psFrmEntNew->pvUsrlHndl = pvUsrHndl;
psFrrnEntNew->iOffStrt = iOf~itrt;
psFrmEntNew->iOff~;trt = iOffNxt;
strcpy((char *)psFrmEntNew ~ sizeof(sFrrnEnt), pczFrrnType);
}
return 0;
int frUpdtFrm (
void *pvUsrHndl,
int iOffStrt,
int iOffNxt
S~ ITE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/14663
-58/24-
if (iSkip) return 0;
if (pvUsrHndl) psF~nFntTail->pvUsrHndl = pvUsrHndl;
if (iOffStrt != -1) psFnnEntNew->iOffStrt = iOffStrt;
if (iOffNxt != -1) psFrrnEntNew->iOffNxt = iOffNxt;
~eturn 0;
char *frGetFrrn (
void **ppvUsrHndl,
int *piOffStrt,
int *piOffNxt
if (ppvUsrHndl) *ppvUsrHndl = psFrrnEntTail->pvUsrHndl;
if (piOffStrt) *piOffStrt = psFrrnEntTail-~iOffStrt;
if (piOffNxt) *piOffNxt = psFrrnEntTail->iOffNxt,
return frGetFrrnTvpe(psFrrnEntTail);
}
void frDoInitFrm(void)
if (iSkip)
iSkip~;
return;
if (!psFrmEntNew) frPutFrrn("default", NULL, 0, 0);
frChkFrrn(frGetFrrnType(psFrmEntTail), frGetFrrnType(psFrrnEntNew));
psFrmEntNew->psFrrnEntNxt = psFrrnEntTail;
SIUts~ JTE SHEET (RULE 26)
CA 02228593 1998-03-03
- W O 97/12339 PCT~US96/1~663
-58t25-
psFrmEntNew->iFrmLvl = psFrmEntTail->iFrmLvl + I;
psFrmEntTail = psFrmEntNew;
psFrmEntNew = NULL;
frInitF~n (
frGetFrmType(psFrmEntTail),
frC~etFrmType(psFrrnEntTail->psFrrnEntNxt)
);
}
void frDoFinFrm(void)
{
psAttrEnt psAttrEntNxt;
psAttrEnt psAttrEntFree;
if(iSkip> 1) {
iSkip--;
return;
}
else if (iSkip) {
iSkip = O;
}
else {
frFinFrrn(frGetFrmType(psFrmEntTail));
}
if (psFrrnEntFree) free(psFrmEntFree);
psFrmEntFree = psFrrnEntTail;
psFrmEntTail = psFrrnEntTail->psFrmEntNxt;
SlJes~ UTE 5! 1 __ I (RULE 26)
CA 02228593 1998-03-03
WO 97/12339 PCTAJS96/14663 -
-58/26-
psFrmEntFree->psAttrEntHead = NULL;
psF~nEntFree->psAttrEntTail = NULL;
psAttrEntNxt= psAttrEntTail;
psAttrEntTail = psFlmEntTail->psAttrEntTail;
psAttrEntWalk = NULL;
while(psAttrEntNxt != psAttrEntTail)
psAttrEntFree = psAttrEntNxt;
psAttrEntNxt = psAttrEntNxt->psAttrEntNxt;
if(psAttrEntFree->pvAttrValBin) {
free(psAttrEntFree->pvAttrValBin);
free(psAttrEntFree->pvAttrValBinCpy);
}
free(psAttrEntFree);
void frDoChlcPt(void)
char aczAttrNmO = "~l~f c
char aczAttrValStr[32];
void *pvAttrValBin;
int iAttrValType = FR_BIN_TYPE;
int iAttrValBinLen = sizeof(int);
int iAttrStat = O;
sprintf(aczAttrValStr, "%d", iChlcPtNwn);
SU.,~ 111 IJTE SHEET (RULE 26)
CA 02228593 1998-03-03
- WO 97/12339 PCTtUS96tl4663
-58/27-
pvAttrValBin = ~iChkPtNum;
f~SetAttrBin (
aczAttrNm,
aczAttrValStr,
pvAttrValBin,
iAttrValType,
iAttrValBinLen,
iAttrStat
~;
iChlcPtNum++;
}
static char *frGetFrmType(psFrmEnt psFrmEntTmp)
{
char *pczFrmType = (char *)psFrmEntTmp + sizeof(sFrmEnt);
return strcpy(pczFrmType + strlen(pczFrmType) + 1, pczFrmType);
}
static char *frGetAttrNm(psAttrEnt psAttrEntTmp)
char *pczAttrNm = (char *)(psAttrEntTmp) + sizeof(sAttrEnt);
return strcpy(pczAttrNm + strlen(pczAttrNm) + 1, pczAttrNm);
SUt~ JTE SHEET (RULE 26)
