Conferencng protocols and Petr net analyss E. ANTONIDAKIS Department of Electroncs, Technologcal Educatonal Insttute of Crete, GREECE ena@chana.tecrete.gr Abstract: Durng a computer conference, users desre to vew the same computer generated nformaton and dsplays. Ths s often accomplshed by communcatng ths nformaton over wdeband lnks to provde realtme dsplays. A concept was developed for communcatng nputs (e.g., keystrokes) nstead of outputs (e.g., dsplays). Technques were desgned to allow two computers to execute the same applcaton program, get the same nputs at the same relatve pont n ther executon, and produce the same outputs. Models were created to descrbe and analyze the way n whch nputs are entered nto executng programs. Protocols were wrtten to dstrbute and synchronze the nputs between the computers. Petr nets were used to valdate the synchronzaton of the nputs. Tmng analyss was performed to guarantee smultanety n executon. Key-Words: -computer conferencng, protocols, smultaneous executon, program synchronzaton, Petr nets 1. Introducton Computer users at geographcally separated stes may desre to vew the same computer generated nformaton and dsplays smultaneously, and thus have a conference. Ths s often accomplshed by communcatng ths nformaton over wdeband lnks to provde real-tme dsplays. Ths paper presents a new approach, whch provdes the same servces wth greatly reduced communcaton requrements. The phlosophy s one of "Compute rather than Communcate." To some degree, the use of computer mage compresson technques and those of transmttng only the changed porton of mages follows ths phlosophy but not to a sgnfcant enough extent. A concept was developed for communcatng nputs (e.g., keystrokes) nstead of outputs (e.g., dsplays). Technques were desgned to allow two computers to execute the same applcaton program, get the same nputs at the same relatve pont n ther executon, and produce the same outputs.models were created to descrbe and analyze the way n whch nputs are entered nto executng programs. Protocols were wrtten to dstrbute and synchronze the nputs between the computers. Petr nets were used to valdate the synchronzaton of the nputs. Tmng analyss was performed to guarantee smultanety n executon. A method has been developed whch wll be called Synchronous Program Executon (SPE) that allows the same program to run synchronously (or smultaneously) on geographcally separated computers. However, the results generated appear to the users at the dfferent stes as f the users are sttng n front of the same computer. The SPE technque can be used n reducng communcatons n cases such as computer conferencng. Synchronzed executon means that the programs must have the "same executon" and be closely synchronzed. In order for the programs to have same executon, they must get the same nput at the same pont n ther executon. Inputs are also used to synchronze the executons of the programs. The nputs can orgnate on any computer and get dstrbuted to the other computers. Input accessng methods are requred to specfy whch computer's nputs are vald at any gven tme durng the conference. The SPE technque s based on the creaton of a Shell runnng at each computer and the transmsson of messages between the Shells. Only a low bandwdth connecton, wth quck response tme s requred between the computer systems. The Shell s constructed at each computer system, n software, and resdes between the operatng system and the executng program and between the enterng nputs and the operatng system. In ths paper, Petr nets are constructed and analyzed that model the synchronzaton of smultaneous program executon between two computers. The nteractons between the Shell, the operatng system and the applcaton program of the two computers, as well as the messages sent between them are modeled wth Petr nets. The analyss of the Petr nets ndcates proper operaton of the system. The analyss ncludes safeness, conservablty and lveness. Programs may execute on computers of dfferent speeds. Ths results n a delay n the executon of the faster computer. Tmng analyss was performed to calculate the delays and the affect they have on the performance of the system.
2. The Shell and the Inputs The Shell can be consdered as an extenson to the operatng system handlng the remote executon secton. It accepts all the nputs to the system, checks f vald, and transmts them to one of the computers called the Master. The Master collects all the nputs, places them n order, appends some synchronzaton nformaton and dstrbutes them to the Slave computer. The Shell s created between the applcaton program and the operatng system and between the nputs and the operatng system. The Shell: 1. runs on both computers 2. gets actvated only by an nput nterrupt and takes the acton shown n 3 or 4 bellow. 3. accepts the nputs and hdes them from the operatng system. If the nputs are vald, t stores them n Temporary Input Buffers (TIB). 4. accepts all requests for nputs and dstrbutes and synchronzes the nputs that are already n the TIBs f any, one at a tme, by communcatng wth the Shell runnng at the other computer. The assumpton has been made that programs requestng nputs, as well as, nputs enterng programs, go through the operatng system. Ths s not a severe restrcton snce most hgh level programs n sngle user systems and all programs n mult user systems are wrtten n ths manner. An applcaton program can request nput n a synchronous or asynchronous manner. The applcaton program can ether wat untl an nput gets entered, n whch case the nput always enters the program at the same pont n ts executon and s synchronous, or, proceed on ts executon and perodcally check for the presence of nput, n whch case t s asynchronous. The number of tmes C that the applcaton program checks for the presence of an nput (through requests to the operatng system), untl the nput gets entered, desgnate the exact pont n program executon that the nput got entered, and s used for the synchronzaton of the asynchronous nputs between the two computer systems. The Shell updates the values of the counter C each tme the applcaton program checks for the presence of an nput. The Shells runnng on the two computers make sure that the nput s presented to the applcaton programs on the same C count. Asynchronous nputs may be entered from ether one of the two computers. An nput accessng method s requred that desgnates what nputs are vald from each one of the two computers at any tme. For example, the keyboards of the two computers may not be actve at the same tme. The user can specfy the nput accessng method that they prefer at the begnnng of the sesson. All the nputs from both computers are presented to the Master where they get valdated and ordered. The Master consders all vald nputs as f they were ts own nputs and dstrbutes them to the Slave, wth some synchronzaton nformaton. The synchronzaton nformaton s the count C. When an nput gets presented to the applcaton programs on the two computers, the count of the Master, Cm, must be equal to the count of the Slave, Cs. Synchronous nputs may be entered from ether of the two computers n whch case they must be dstrbuted to the other computer. Synchronzaton s not requred but valdaton s. There are cases where synchronous nputs may orgnate from data that exsts on both computers, lke readng of fles that exst on both computers. In such cases the applcaton program can tself get the nput (through the operatng system) wthout any acton to be taken by the Shells. The rest of the paper s about the asynchronous nputs. 3. Asynchronous Input Synchronzaton Petr nets are used for modelng the synchronzaton of the asynchronous nputs. One of the most mportant use of Petr nets s the modelng of asynchronous systems, especally ones that experence concurrency, asynchronsm and nondetermnsm [1]. The system under constructon possesses all three condtons. The system experences concurrency snce there s executon takng place at two computers. It experences asynchronsm snce some nputs are entered n an asynchronous way. Fnally, t experences nondetermnsm, n ts executon, snce the nputs are entered nteractvely, whch means that the executon takes a path related to the user response. In Petr net language, ths s called decson or data-dependency. For the analyss that wll follow we adopt basc Petr net theory, notaton and formulaton of Coolahan and Roussopoulos[2]. In fgure 1 s the Petr net model of a runnng process that checks for an nput. Place p1 represents the applcaton process that s executng. When the process wants to check for an nput, transton t1 fres and the token goes to place p2. Transton t1 s the call to the operatng system to check for an nput. In p2 the checkng for an nput s performed by the operatng system. If no nput s avalable, then transton t2 fres and the token returns to p1 where the user process resumes
executon. The token loops n p1, t1, p2, t2 untl an nput s entered. After an nput s entered, the next tme that the token gets n p2, transton t25 wll fre and the loop wll termnate. The token goes to p23 where the user process gets the nput. Then transton t26 fres and the token returns to p1 where the user process returns to processng. Ths scenaro wll contnue as long as the process s executng. When the process termnates, transton t3 fres and the token returns to the operatng system, place p3. The numberng of places and tokens s not done consecutvely n fgure 1 as ths wll be part of the bgger pcture n fgure 3. p1 t3 p3 t1 t26 p2 t2 p23 t25 - User Process - Operatng system Fg. 1 Petr net of a User Process checkng for nputs In fgure 1 s the Petr net model of a runnng process that checks for an nput. Place p1 represents the applcaton process that s executng. When the process wants to check for an nput, transton t1 fres and the token goes to place p2. Transton t1 s the call to the operatng system to check for an nput. In p2 the checkng for an nput s performed by the operatng system. If no nput s avalable, then transton t2 fres and the token returns to p1 where the user process resumes executon. The token loops n p1, t1, p2, t2 untl an nput s entered. After an nput s entered, the next tme that the token gets n p2, transton t25 wll fre and the loop wll termnate. The token goes to p23 where the user process gets the nput. Then transton t26 fres and the token returns to p1 where the user process returns to processng. Ths scenaro wll contnue as long as the process s executng. When the process termnates, transton t3 fres and the token returns to the operatng system, place p3. The numberng of places and tokens s not done consecutvely n fgure 1 as ths wll be part of the bgger pcture n fgure 3. The handshake of messages between the two computers for synchronzng one asynchronous nput s shown n fgure 2. The messages exchanged are symbolzed msgx and they are not numbered consecutvely or n order. If the nput s from the Slave, the Slave sends the nput to the Master wth msg6 and the Slave proceeds on ts executon. The Master receves msg6 and checks f the Slave has access of the nputs. If t does, the Master accepts the Slave s nput and consders t as one of ts own, otherwse t dscards the key. Cm Cs msg6 msg5or9 msg3or4 MASTER SLAVE Fg. 2 Handshakng for Asynchronous Input Synchronzaton If the Master has an nput, t sends a msg5 to the Slave wth the nput and counter, Cm. If that nput was a Slave nput that arrved at the Master wth a msg6, then t s msg9 nstead of msg5. When the Slave receves msg5 or msg9 wth the nput and Cm, t compares Cm wth ts own count Cs. If Cs<=Cm then the Slave contnuous executon to catch up wth the Master (Cs=Cm) and then t sends msg3 to the Master. If Cs>Cm then the Slave sends msg4 to the Master wth ts count Cs and wats. When Master receves msg3 t puts the nput n effect, sends to the Slave and resumes executon. If Master had receved msg4, t contnues executon untl Cm=Cs. Then t puts the nput n effect, sends to the Slave and resumes executon. When Slave receves t puts the nput nto effect and resumes executon. The above actons of transmttng and recevng messages, comparng counts, etc, takes place n the Shells runnng at the Master and the Slave. Ths s shown n detal n fgure 3. Methodology on how to use Petr nets to represent communcaton protocols was found n [3] and [4]. Fgure 3 dsplays the Petr net that represents the communcaton protocol for the synchronzaton of the nputs. Ths Pert net s dvded nto three parts wth the dotted lnes: the Master, the Slave and the Communcaton (COMM). Ths Pert net models the handshake of fgure 2. Fgure 1 shows how a program requests and gets an nput, and fgure 3 shows how two programs request and get the same nput at the same pont n ther executons wth the help of the Shell. The nput accessng method modeled on ths Petr net s that the nputs from the Master and the Slave are allowed n the order that they arrve at the Master. No nputs are deleted
unless the TIBs local to each machne, get full. The nputs are processed one at a tme. t3 p3 t26 t1 t23 p21 p22 p1 t13 p2 t2 p11 p23 t24 p12 t25 MASTER COMM SLAVE t12 t11 t22 p8 wat p20 t14 p13 t8 t21 p7 msg6 msg5or9 p14 msg3or4 p19 p24 t15 p9 t10 t20 p15 p18 wat - User Process - Operatng System - Shell Process - all three Fg. 3 Pert net for synchronzng the asynchronous nputs The places on the Petr net represent processng or checkng of smple condtons. The processng can be part of the applcaton (user) process, of the Shell process, or of the operatng system. The transtons on the Petr net represent events happenng. The Petr net of fgure 3 conssts manly of: a) fve loops b) four messages c) two wat states d) some extra processng states. The fve loops are, frst: p1, t1, p2, t2; second: p4, t4, p5, t5; thrd: p9, t9, p10, t10; forth: p16, t18, p17, t19; ffth: p21, t23, p22, t24; The four messages are: frst s "msg6": p7, t8, p8; second s "msg5" or "msg9": p14, t15, p15; thrd s "msg3" or "msg4" :p19, t21, p20; and forth s "": p24, t27, p25. Messages consst of three felds: 1. type of message (or msg number) 2. nput nfo 3. local counter (Cm or Cs). In the case of keyboard nputs, the message type feld s one byte long, the nput nfo feld s two bytes: one byte for the ASCII code of the key and t27 p25 t5 t16 t7 p10 p4 t9 t19 t28 p5 p26 t4 t6 p16 t17 p17 p6 t18 t29 one byte for the extended code or scan code of the key, and the counter feld can be of fxed or varable sze. A varable length counter feld requres the message to have a forth feld contanng the message length. The two wat states are: frst: t14, p13, t22; second: t20, p18, t28. In the frst loop, n p1, the user process s runnng and when t checks for nput transton t1 fres and the token comes to p2. As was seen n fgure 1 ths would be a call to the operatng system, checkng for nputs, but n ths case p2 s the Shell whch ntercepts the calls of the user process to the operatng system concernng nput. In p2 the shell wll check f a msg6 has arrved from the Slave holdng an nput (token n p8) and then transton t11 would fre. If no msg6 has arrved from Slave then f a local nput has been nserted at Master, t13 wll fre; else t2 wll fre and the token returns to p1 where the Master user process resumes executon. Whle a token s ready at p2, prorty s gven frst to t11 to fre, then to t13 and last to t2. All loops work n a smlar manner. Lookng at these fve loops n fgure 3, the top place of each loop s executon of the user process, and counter C ncrements by one each tme the token passes through. The bottom place s executon n the shell that checks condtons and prortes. All actons requred to synchronze the nputs are taken whle executng n the Shell. In the second loop, n place p5 prorty s gven frst to t17 to fre f a message has arrved from the Master. If no message from the Master s avalable, f an Slave nput s avalable the t7 wll fre. Otherwse, t5 wll fre. In the thrd loop, n place p10, prorty s gven frst to t16 to fre f a message from Master has arrved, else t10 wll fre. In the fourth loop, n place p17, t20 wll fre f Cs>=Cm+1; else (f Cs<Cm+1) t19 wll fre. In the ffth loop, n place p22, t24 wll fre f Cm<Cs; f Cm=Cs t25 wll fre. Examples of the Executon of the Pert net. Case 1: Master gets nput (key located n one of ts TIBs). The user program starts at p1 for Master and at p4 for the Slave. Whle Master s watng for key (Master keyboard TIB s empty), Master s loopng at p1, t1, p2, t2 and Slave s loopng at p4, t4, p5, t5, Master presses a key (key n TIB placed there by the Shell hdng the key from the operatng system). Next tme the Master gets at p2, t13 wll fre and p12 wll prepare msg5 to send to Slave contanng the key and Cm. When t14 fres msg5 s
send to Slave and the Master wats at p13. In p14 takes place the transmsson of msg5 and t15 fres when msg5 arrves n the Slave. In p15 the computer where the Slave process s runnng receves msg5. The Slave process s executng n the loop p4, t4, p5, t5 and next tme the token gets to p5, t17 wll be enabled and wll fre to p16. At p16 the Slave user process resumes, and the Slave wll loop n p16, t18, p17, t19 untl Cs>=Cm+1. Durng ths loop the Slave user process has the chance to catch up wth the Master user process f necessary. Whle at p17, t20 wll fre and the Slave wll wat at p18 whle a msg3 (f Cs=Cm+1) or a msg4 (f Cs>Cm+1) s sent to Master. The transmsson takes place at p19. When t21 fres, msg3 or msg4 has arrved at Master and s receved at p20. A ready token at p20 resumes the wat of the Master at p13. t22 fres and Master user process resumes executon. Master loops at p21, t23, p22, t24 untl Cm=Cs. Ths gves a chance for Master user process to catch up wth the Slave user process. Whle at p22, t25 wll fre (Cm=Cs). A token goes at p23 where the nput s passed to the Master user process, Cm s set to zero, and eventually t26 fres and the token returns to the Master user process at p1. Another token s sent to p24 whch s transmtted to the Slave. When t27 fres, has arrved at Slave and s receved at p25. A ready token at p25 resumes the wat of the Salve at p18. When t28 fres the token goes at p26 where the nput s passed to the Slave user process, Cs s set to zero, and eventually t29 fres and the token returns to the Slave user process at p4. Note that the nput passed to the Slave user process (p26, t29) could take place durng the wat (t20, p18, t28). In other words p26 s executed before p18. Thus the wat s replaced by t20, p26, t29, p18, t28 and the frng of t28 returns the token to p4. For =23, and for =26 p p a t a p b t b p c - User Process - Operatng System - Shell Process - all three At p23 and p26 the nput was passed to the Master or Slave user process respectvely. The Shell presents the nput, whch n ths case s a keystroke entered n the keyboard buffer of the Master or the Slave. A call to the operatng system s nvoked from the Shell to check for an nput (key). The call to the operatng system returns that an nput s present. Snce an nput s present, a call from the user process to the operatng system may follow, to read and process the nput. The token returns to p1 or p4 to start processng the next nput. Case2: Slave gets an nput (keypress). Master s loopng at p1, t1, p2, t2 and Slave s loopng at p4, t4, p5, t5 watng for a key. When the Slave gets an nput, next tme the token gets to p5, t7 wll fre. A token goes to p7 where msg6 s transmtted to Master, and another token goes to p9 makng the Slave loop n p9, t9, p10, t10. When msg6 arrves at Master, t8 fres and a token goes to p8 where the Master receves msg6. The token at p8 wll break the loop p1, t1, p2, t2 next tme the token comes around to p2. t11 wll fre, the token goes to where the Slave's nput s consdered as Master's nput. t12 fres and the token goes to p12 where Master assembles msg9 (nstead of msg5 snce t s Slave's nput) and when t14 fres t transmts t to the Slave. Master s watng at p13. When msg9 arrves at the Slave, t15 fres and a token comes to p15 where the Slave receves msg9. Snce the Slave s loopng at p9, t9, p10, t10, next tme t comes around to p10, t16 fres and a token comes to p16. From then on s the same as n Case1 above. 4 Petr Net Analyss Analyss on the Pert net was performed to ensure the proper operaton of the system. The reachablty tree was constructed and studed. Conclusons of the reachablty tree are: 1. All the places n the Petr net are safe except place p8 where t s 2-bounded. But that s not a problem snce p8 s a buffer that can hold two messages. Safeness s a property that must hold n order for the system to work properly. Each place represents the executon of a routne. Safeness states: never more than one token at any place. Assume that a token arrves at a place, whch means that a routne wll start executng. If another token arrves at the same place before the frst routne fnshes executng, another routne (wth the same code) wll start executng and the frst routne wll stop, causng the system to be n an unknown and unwanted state and therefore unable to recover. 2. The Petr net s not conservatve snce the number of tokens n the net does not reman constant. Even though the number of tokens s not constant, t can be noted that there s one "resdent" token at the Master and one at the Slave at all tmes that show where the Master and the Slave currently execute. In addton, there are some extra tokens generated and deleted upon the transmsson and
recepton of messages that desgnate processng at communcatons processors. 3. The Pert net s lve, whch means that all the transtons are lve and that there are not any deadlocks. The protocol s wrtten s such a way that no message can be transmtted unless all prevous messages have been receved properly. There exst communcatons processors that handle the transmsson and recepton of messages and the retransmssons f necessary. Ths takes place at a lower level not seen and not affectng ths Petr net. At ths level, we assume that all messages arrve properly. For further analyss on the Pert net and on other Petr nets modelng for dfferent nput accessng methods refer to [5]. 5 Tmng Analyss Suppose that the Master executes three tmes faster than the Slave. The Master process s checkng for the presence of nputs three tmes faster than the Slave process. Fgure 4 shows the requests for nput of the Master and Slave processes to the operatng system. These are denoted as markngs on the Master and Slave axs respectvely. Also shown are all the messages to synchronze a key that was pressed by the user at the Slave machne. MASTER 1 5 1 SLAVE 10 msg6 Slave presses key msg5 5 CUT 10 13 Master processes key 13 msg3 Slave processes key Fg. 4 The Catch Up Tme (CUT) On the left sde of fgure 4, desgnates the end of the synchronzaton of the prevous nput. After the last synchronzaton, the Master and the Slave keep track of how many tmes the applcaton process asks the operatng system to check for the presence of nputs, counters Cm and Cs respectvely. Slave presses a key when Cs=2 and next tme the Shell gets access (Cs becomes 3), msg6 s send to Master. Master receves msg6 at Cm=11 and gets processed when the Shell at Master gets access (Cm becomes 12). Master compares counts and sends msg5 and Slave receves t at Cs=4 and wll process t when Cs=5. Then the Slave has to catch up, and the Master has to wat for the Slave. At Cs=13 the Slave sends msg3 to the Master and stops ts wat. On the next 1 1 Master count, Cm=13, Master sends and a new synchronzaton phase starts. It s noted that the Master process had to wat dle for an nterval of 8*Ts, where Ts s the tme nterval between two consecutve tmes that the Slave checks for nputs, whle the Slave catches up. Ths tme nterval wll be the Catch Up Tme (CUT) of the slower process. The CUT must be such that the responsveness of the system, from the moment that an nput s entered tll the moment the nput s regstered by the process, s n acceptable values for the users. That value wll be called the Maxmum Allowable Wat Interval (MAWI). It s of nterest to note that, even f the Master was executng dle loops watng for an nput, the Slave stll has to do "dle catch up". In other words, the CUT of the Slave does not do any useful processng. The Slave's dle catch up cannot be elmnated snce there s no way of knowng what the user process s executng wthout nterferng wth the process. The more often the computers communcate, the closer they reman synchronzed and the smaller the CUT requred to regan synchronzaton on the next handshake. On the other hand, the more often the computers communcate, a hgher bandwdth s requred and less processng s acheved. When some tme passes wthout handshake (a tmer expres), the Master computer ntates communcaton by ntroducng a null key whch s removed after t gets synchronzed. The users can set the value of ths tmer and tune he responsveness of the system to ther needs. In other words, they can set up the value for the MAWI. When the counter at the Master or the Slave approaches overflow a handshake wth a null key s forced, ntated from the process whose counter approaches overflow. The worst case response (WCR) tme of the system s equal to the CUT plus four Communcaton delays (ComDelay). Where ComDelay s the transmsson tme of a message. The Slave nput gets synchronzed wth three messages to the Master and wth four messages to the Slave. A Master nput gets synchronzed wth two messages to the Master and wth three messages to the Slave. All messages are less than 10 bytes long. 6 Concluson The SPE technque helps to reduce communcatons n cases such as computer conferencng. Applcaton programs can execute synchronously at geographcally separated computers. Conferencng can take place through an
applcaton program. For example, f the conference s about the desgn of a buldng, the conference supportng program or applcaton program could be AutoCad TM. The nputs to the program, orgnatng from ether computer accordng to an nput accessng method, and some mnmal synchronzaton nformaton, such as the counts, are the only data that has to be communcated between the two computer systems. Wth exstng methods of computer conferencng, executon takes place on one computer and every tme the screen changes, the screens or the changes of the screens have to be communcated to the other computer. When the SPE technque s appled to computer conferencng, only the nputs to the program, such as the keystrokes, have to be communcated. Teamwork wll be promoted even f ts members are physcally separated. Collaboraton can take place wth the use of exstng, off the shelf software, and wthout any added hardware. Tutorng the use of software, debuggng software, tutorng a subject through an applcaton program, are some aspects that can take place remotely wth the proposed approach. Applcaton programs that produce many screens at a hgh frequency are currently unable to be used remotely unless hgh bandwdth s provded. Usng the proposed approach may allow communcatng over exstng telephone lnes. Graphcal programs ordnarly requre consderable bandwdth. However, usng the SPE approach allows them to run remotely over low speed lnes. Securty s embedded n the communcatons when done wth the proposed method. There are many crcumstances where the nputs to generate the screens are not classfed, whle the generated screens (outputs) are classfed. Many computer users who would lke to have a sesson through ther computers, wll be greatly benefted from the results of ths work. Internatonal Conference on Dstrbuted Computng Systems, October 18-22, 1982. [4] P. Merln, "A Methodology for the Desgn and Implementaton of Communcaton Protocols", IEEE transactons on Communcatons, Vol. 24, No. 6, June 1976, pp. 614-621. [5] Emmanouel Antondaks, "Communcatons Reducton Usng Smultaneous Program Executon," Ph.D. dssertaton, Department of Electrcal Computer and Systems Engneerng, Boston Unversty, Boston, MA, 1993. References: [1] J. L. Peterson, Petr Net Theory and the Modelng of Systems, Prentce- Hall, Inc., Englewood Clffs, N.J., 1981 [2] J. E. Coolahan Jr. and N. Roussopoulos, "A tmed Petr net methodology for specfng real-tme system tmng requrements," Internatonal Workshop on Tmed Petr Nets, Torno, Italy, July 1985. [3] S. M. Shatz and S. S. Yau, "The Applcaton of Petr Nets to the Representaton of Communcaton In Dstrbuted Software Systems," Proceedngs of the 3rd