CA2228593A1 - Computing system for processing information flows - Google Patents

Abstract

A general purpose procedure can process information flows which are represented by a sequence of frames. Any frame may have any number of attributes, each of which has a type and a value. An attribute can also be a frame, thereby permitting recursive processing of information flows. Common processing of frames is encapsulated into a single procedure that can handle information flows having a wide variety of syntactic and semantic characteristics. The single procedure can process communication protocols, intracomputer communications and security encryption protocols at the same time. The procedure can also be embodied in hardware or firmware.

Description

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

- 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 -- W O 97/12339 PCT~US96/14663 -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 ç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

-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 -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' _ 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 -- W O 97/12339 PCTnUS96/14663 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.

- 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).

~ W O 97/12339 PCTAUS96/14663 -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 - 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 - WO 97/12339 PCT~US96/14663 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 -.)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 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).

. --- W O 97/12339 PCT~US96/14663 -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 _ - W O 97/12339 PCT~US96/14663 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', - W O 97/12339 PCT~US96/14663 --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 - W O 97/12339 PCT~US96/14663 -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 --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, ~ WO 97/12339 PCT~US96/14663 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.

- W O 97/1~339 PCT~US96/14663 --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 W O 97/12339 PCT~US96/14663 --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 ~ W O 97/12339 PCT~US96/14663 -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 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.

WO 97/12339 PCT~US96/14663 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) - W O 97/12339 PCT~US96/14663 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) - W O 97/12339 PCTrUS96/14663 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) - 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) - W O 97/lZ339 PCTAJS96/14663 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) 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) , -- 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 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) - 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) WO 97/12339 PCT~US96/14663 /* 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) - 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) 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) - W O 97/12339 PCTrUS96/14663 _ -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) . WO 97/12339 PCTfUS96/14663 _ 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) ) (F2 (al vll) ~ (a4 v44) ) (a2 V22) ) SIJCS~ JTE SHEET (RULE 26) - WO 97/12339 PCT~US96/14663 -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) -- W O 97/12339 PCT~US96/14663 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) W O 97~12339 PCTAUS96/14663 . 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) 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) - 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) 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) - WO 97/12339 PCT~US9G/14663 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) - W O 97/12339 PCT~US96/14663 _ 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 W O 97/12339 PCT~US96/14663 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~

WO 97/12339 PCT~US96/14663 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) -' W O 97/12339 PCTAUS96/14663 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) .

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) - 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) - 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) 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) 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) - W O 97/12339 PCTrUS96/14663 -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) - W O 97/1Z339 PCTrUS96/14663 _ :

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) WO 97/12339 PCT~US96114663 *~
/* 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) - W O 97/12339 PCTrUS96/14663 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) 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) - WO 97/12339 PCT~US96/14663 }

<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) - 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) - WO 97/12339 PCT~US96/14663 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) - WO 97/12339 PCTnUS96/14663 -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 -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) - W O 97/12339 PCT~US96/14663 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) W O 97/12339 PCTrUS96/14663 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) _ 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) W O 97/12339 PCTAUS96/14663 _ -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) - W O 97/12339 PCTrUS96/14663 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) - W O 97/12339 PCTrUS96/14663 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) - W O 97/12339 PCTAJS96/14663 _ -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) - W O 97112339 PCT~US96/14663 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 - W O 97/12339 PCT~US96/14663 _ -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) - W O 97/lZ339 PCTnUS96/14fi63 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) - WO 97/12339 PCTrUS96/14663 -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) _ - W O 97/12339 PCT~US96/14663 _ -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) - W O 97/12339 PCT~US96/14663 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 . W O 97/12339 PCT~US96/14663 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) W O 97/12339 PCT~US96/14663 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) - W O 97/12339 PCTnUS96/14663 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) - W O 97/12339 PCT~US96/14663 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) - 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) 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) - WO 97/12339 PCTtUS96tl4663 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)

Claims (20)

The invention claimed is:

1. A computing system comprising:
a) an information flow represented as sequential frames to be processed by the computing system, each frame being a set of attributes and each attribute having a type and a value;
b) a plurality of action routines for processing the values; and c) a general purpose processing engine responsive to the frames, the processing engine invoking select action routines in response to the frames.

2. The computing system of Claim 1 wherein the information flow is a protocol-based interprocessor communication.

3. The computing system of Claim 1 wherein the processing engine includes a common core engine and a plurality of support routines.

4. The computing system of Claim 3 wherein the support routines operate on at least one hierarchical memory store.

5. The computing system of Claim 4 wherein the at least one hierarchical memory store includes a stack of attributes.

6. The computing system of Claim 5 wherein the at least one support routine generates synthetic attributes for storage in the stack of attributes.

7. The computing system of Claim 1 further comprising at least one adapter routine in communication with the processing engine, each adapter routine parsing a select information flow into frames.

8. The computing system of Claim 1 wherein the information flow is processed in a multi-threading architecture.

9. The computing system of Claim 8 wherein serial frame sequences are processed in parallel.

10. The computing system of Claim 8 wherein frame sequences are pipelined between threads.

11. In a computing system, a method of processing an information flow, comprising the steps of:
representing an information flow as sequential frames to be processed by the computing system, each frame being a set of attributes and each attribute having a type and a value;
in a plurality of action routines, processing the values; and in a general purpose processing engine responsive to the frames, invoking select action routines in response to the frames.

12. The method of Claim 11 wherein the information flow is a protocol-based interprocessor communication.

13. The method of Claim 11 wherein the processing engine includes a common core engine and a plurality of support routines.

14. The method of Claim 13 wherein the support routines operate on at least one hierarchical memory store.

15. The method of Claim 14 wherein the at least one hierarchical memory store includes a stack of attributes.

16. The method of Claim 15 wherein the at least one support routine generates synthetic attributes for storage in the stack of attributes.

17. The method of Claim 11 further comprising the steps of:
providing at least one adapter routine in communication with the processing engine; and in each adapter routine, parsing a select information flow into frames.

18. The method of Claim 11 wherein the information flow is processed in a multi-threading architecture.

19. The method of Claim 18 wherein serial frame sequences are processing in parallel.

20. The method of Claim 18 wherein frame sequences are pipelined between threads.