Proceedings of the 1996 Winter Simulation ConfeTenceed. J. !vI. Charnes, D. J. Morrice, D. T. Brunner, and J. J. S\vain

A CORBA FACILITY FOR NETWORK SIMULATION

Chien-Chung Shen

Bellcore331 Newman Springs Road

Red Bank, New Jersey 07701, U.S.A.

ABSTRACT

Contemporary software development environmentsfor discrete-event simulation have adopted eithera language-based approach or a library-based ap­proach. Although these approaches have advantagessuch as type checking and optimized code generationprovided by the former and familiar programming en­vironments facilitated by the latter, they suffer fromthe inherent limitations of model portability and in­teroperability, which may result in inflexible modelsand higher model development cost. This paper pro­poses a CORBA discrete-event simulation facility tofacili tate portable and interoperable simulation mod­els. The proposed facility is defined by a CORBA IDLinterface which defines operations for object defini­tion, inter-object communication and event schedul­ing. Based on the given IDL interface definition, dif­ferent vendors could supply different products (at dif­ferent costs) by using different simulation algorithms,different programming language, or on different op­erating system or hardware platforms. With respectto the simulation models, they see a consistent in­terface across all products. The paper presents thesimulation facility IDL interface, describes its proto­type implementation in C++, and illustrates its usageby a bounded-buffer producer-consumer example.

1 INTRODUCTION

Contemporary software development environmentsfor discrete-event simulation have adopted either alanguage-based approach or a library-based approach(Martin and Bagrodia 1995). In either case, pro­grammers are provided with a set of model definitionprimitives together with a set of parallel program­ming primitives for object definition and inter-objectcommunication and synchronization. These primi­tives are provided either as language extensions or asfunctions implemented as library routines. Although

these approaches have advantages such as type check­ing and optimized code generation provided by theformer and familiar progran1n1ing environments facil­itated by the latter, they suffer from the following twoinherent limitations.

• Portability. Simulation models developed us­ing one sin1ulation language might not be easilyported to another sinlulation language. The pro­grammers will be required to learn new languageconstructs and perhaps an entirely new set ofprogram development tools.

• Interoperability. Components of a simulationmodel are required to be programmed in thesanle host language dictated by the simulationlanguage or library routines used. It is, so far,infeasible that a simulation model consists of in­teroperable components written in different pro­gramming languages, or running on different op­erating systenls or hardware platforms.

These limitations may potentially lock simulation ap­plication development into a particular (vendor) en­vironment and result in inflexible models and highermodel development cost.

However, these restrictions are not inherent in sim­ulation application development alone. In fact, oneof the most difficult tasks challenging information in­dustry today is to enable application interworkingand construction in a distributed, heterogeneous, andmulti-vendor environment.

Confronted with the challenge, the Object Man­agement Group (OMG) was founded in 1989 to de­velop a set of standards, using object technology, tofacilitate distributed computing, which guarantee ap­plication interoperability and portability. Amongthem, the Common Object Request Broker Architec­ture (CORBA) (OMG 1993) has emerged as a defacto standard for distributed object computing.

At its core, CORBA defines the facilities requiredto allows a client object to transparently invoke the

614

services offered by CORBA-compliant objects (orCORBA objects for short) running on any machinein a heterogeneous distributed environn1ent. The re­mote CORBA object are available across differentoperating systen1s (UNIX, Windows, OS/2, MVS),and different progran1ming languages, such as C++,C, Ada, and Java, with many others to follow.

Each CORBA object has an interface that definesthe services it offers to its clients, and this interfaceis defined in an Interface Definition Language (IDL)specified by the CORBA standard. The CORBA IDLis not a programming language and it does not replacethe use of programming languages. Instead, the IDL'sonly role is to define interfaces which consist of oper­ations available to the clients of the interfaces.

The advantage of using CORBA IDL is that it al­lows a CORBA object to define its interface (services)in a declarative fashion, which is independent of theprogramming language used to implement the objectitself, or the progran1ming language used to imple­ment the clients of the object. In particular, the lan­guage used to implement CORBA objects need notbe the same as that used by clients, and of course, theclients that invoke a given CORBA object need not allbe implemented in the san1e programming language.For example, a client object written in Ada need notbe aware that a CORBA object it is invoking is im­plemented in C++. In this case, the IDL definition ofthe object interface is translated, through an appro­priate IDL con1piler, automatically into Ada for thebenefit of the client, and into C++ for the benefit ofthe implen1enter of the interface.

In this paper, we propose a CORBA discrete-eventsimulation facility using the message-based approach(Bagrodia, Chandy, and Misra 1987). The facility ex­ports an interface, defined in CORBA IDL, consistingof operations for object definition, inter-object com­munication and event scheduling, and implements theinterface using a discrete-event simulation algorithm.Simulation models utilizing the facility shall first bindto the facility (as an object) and then invoke the ex­ported operations to obtain runtime support for exe­cuting simulation models.

Based on the proposed interface definition, differ­ent vendors are encouraged to supply different prod­ucts (at different costs) by using different simula­tion .algorithms, di.fferent programming language, oron dIfferent operatIng system or hardware platforms.However, with respect to the simulation models, theysee a consistent interface across all products.

The remainder of the paper is organized as fol­lows. We first present an overview of CORBA in thenext section. The concept of message-based discrete­event simulation is introduced in Section 3. Based

Shell

Figure 1: Object Management Architecture (OMA)

on that, we define a discrete-event simulation fa­cility and present its CORBA IDL interface defini­tion in Section 4. Section 5 describes its prototypeimplementation. Application of the facility usinga bounded-buffer producer-consumer example is de­scribed in Section 6, and Section 7 is the conclusion.

2 DISTRIBUTED OBJECT COMPUTINGWITH CORBA

To enable distributed application interworking andconstruction, OMG defines the Object ManagementArchitecture (OMA) Reference Model (OMG 1992)which identifies and characterizes the components,interfaces and protocols necessary to guarantee inter­operability and portability of distributed applicationsin heterogeneous environments.

2.1 The OMA Reference Model

T.he .OMA defines a reference model (Figure 1) fordIstrIbuted object computing. Within the referencemodel, the most important component is the ObjectRequest Broker (ORB). An ORB provides the basicmechanism for transparently making requests to andreceiving responses from objects located locally or re­motely without the client needing to be aware of themechanisms used to communicate with the objects.As such, the ORB forms the foundation for build­ing applications constructed from distributed objectsa~d for interoperability between applications in dis­trIbuted heterogeneous environments.

Every entity in the reference model is modeled asan object. These objects comn1unicate with eachot~er via the ORB. According to their functionality,objects are categorized into three groups:

• Object Services comprise a collection of ser­vices (interfaces and objects) that provide ba­sic functions for using and implementing objects.

A CORBA Facilit.y for Netlvork Simulation 615

Examples are naming and event services.

• Common Facilities provide a collection ofcommonly-found services useful in many appli­cations. In contrast to Object Services whichare general purpose and application-domain in­dependent, Common Facilities are services whichare often application-domain specific and typi­cally provide functionality directly to end-users.The simulation facility is an example.

• Application Objects are objects specific toparticular end-user applications. Examples aresimulation and banking applications.

2.2 The CORBA Architecture

The CORBA specifies a concrete description of theinterfaces and services that must be provided by com­pliant Object Request Brokers. CORBA is composedof the following five major components.

• ORB Core. The ORB Core provides the ba­sic communication capability between objects. Itsupports two different ways in which clients canmake requests to objects: static invocation viainterface-specific stubs and skeletons compiledfrom IDL interface definitions, and dynamic in­vocations via the Dynamic Invocation Interface.No matter which of these methods is used by aclient to make a request, the ORB Core locatesthe desired object, activates it if it is not alreadyexecuting, and delivers the request to it. The ob­ject performs the requested service and returnsany result back to the ORB Core which then re­turns it to the client.

• Interface Definition Language (IDL). InCORBA, object services are defined as interfacesin IDL, a language-independent declarative lan­guage. IDL supports (multiple) inheritance inwhich derived interfaces inherit the operationsand types defined in their base interfaces.

• Interface Repository (IR). The IR providespersistent storage for IDL interface definitions.Its primary function is to provide the interfaceinformation necessary to issue requests using Dy­namic Invocation Interface.

• Dynamic Invocation Interface (DII). Sonleapplications, such as browsers, require the ca­pability of sending requests to objects withouthaving compile-time knowledge of their interfacedefinitions. The DII allows run-time discoveryof interfaces fronl an IR, dynamic creation andinvocation of requests to objects.

Figure 2: The CORBA Components

• Object Adaptor (OA). An object adaptorprovides the means by which various types ofobject implementations can utilize ORB services,such as object method invocation, activation anddeactivation of objects and inlplementations.

Figure 2 shows how the various CORBA componentsworking together to facilitate distributed object com­puting. We assume that a client wants to invoke aservice supported by an object. An IDL definitionfile is created to describe the interface (services) theobject provides, which is stored in the IR as well ascompiled into an IDL Stub and an IDL Skeleton. Theclient can initiate a request by calling the IDL Stub.Alternatively, the client looks up the IR and dynam­ically creates and invokes a request using DII. In ei­ther case, the request is directed to the ORB Core.The ORB Core locates the object implementation andthen delivers the request to the OA managing that ob­ject. The OA feeds the request into the IDL Skeletonwhere it is then passed to the object implementation.Any return values are passed back through the IDLSkeleton and OA to the ORB Core. Then, dependingon the original call, the ORB Core returns the valueeither through the IDL Stub or the DII to the client.

3 MESSAGE-BASED DISCRETE-EVENTSIMULATION

In this section, we review the basic concept ofmessage-based discrete-event simulation which pro­vides a nl0re natural paradigm for simulating dis­tributed systenls, and therefore better serves as thefoundation for the definition of a simulation facility.

In message-based simulation, each physical entityis abstracted by an logical object (10), and interactionsamong the entities, called events, are represented bynlessage comnlunications anl0ng the corresponding

616

clock = 0;Initialize event-list;while (execution not terminated) do{ fetch next tuple (mi' Si, d i , ti) from event-list;

if (mi is a tinleout message) then clock = ti;deliver mi to di for simulation;

}

Figure 3: Message-Based Simulation Algorithm

10. (Symbol 10 represents both singular and pluralforms.) A message-based simulation algorithm usestwo data structures (Misra 1986): a si'mulation clockand an event-list (Figure 3). The simulation clockgives the time up to which the physical system hasbeen simulated. The event-list is a partial order oftuples; a tuple is represented by (m, s, d, t), where mrepresents a message, sand d are the source and des­tination 10 for 1TI, and t is a timestamp. The partialorder is typically based on the timestanlp and en­sures that events are simulated in the order of theirdependencies. At every step of the sinlulation, thealgorithm selects the tuple with the smallest times­tamp, say (mi' Si, di , ti), removes it from the event­list, and delivers m·i to di . Multiple tuples with thesame timestamp may be handled in an arbitrary or­der, or be ordered deternlinistically using transparentsequence numbers to reflect their dependencies. Thesimulation of m·i by /0 di 1l1ay generate additionalmessages which are added to the event-list.

During the execution of a silllulation progranl,the simulation clock advances in a m.onotonic non­decreasing manner through the tinlestanlps associ­ated with each tuple. Note that the simulation clockis completely decoupled fronl the physical processorclock. The physical tinle required to sinlulate a mes­sage does not have any effect on the simulation clock.How is the timestamp assigned to a message? Whena message is generated, it is timestamped with thecurrent value of the sinlulation clock - with one ex­ception. We define a special message called a timeoutmessage. The timeout message is scheduled by an 10for delivery to itself at a fut-ure time and is typicallyused to sinlulate the tin1e of a sinlulation step thatwould be required by the physical entity to executethe corresponding operational step. An operationalstep refers to the statenlents executed by a physi­cal entity to process a 111essage received by it, and asimulation step n10dels the activities that would beexecuted by the corresponding operational step. Forexall1ple, consider a file-handler entity. On receivinga read request for the file, a physical (operational)file-handler will read the appropriate record from the

file and return it to the requesting entity. If the file­handler is abstracted by a logical object, on receivinga read request, the 10 estimates t, the time requiredfor the corresponding physical entity to read the fileand schedules a timeout message to itself t time unitslater. As the timestamp on all messages other thanthe timeout message refers to the current value of thesimulation clock, the simulation time advances onlywhen a timeout message is delivered to an 10.

4 SIMULATION FACILITY

In light of the above description, we define theDESFacility interface (Figure 4), in CORBA IDL,for 1l1essage-based discrete-event simulation, whichconists of operations for object definition, inter-objectcommunication and event scheduling.

typedef string ObjName;typedef string MsgType;typedef any MsgContents;typedef long Time;typedef boolean BGuard;

struct WCltem {MsgType msg_type;BGuard bguard;Time duration;

} ;

typedef sequence<WCltem> WaitCondition;

struct Message {ObjName source;ObjName sink;MsgType msg_type;MsgContents contents;

} ;

interface DESFacility {void role(in ObjName myself);void enroll(in ObjName myself);void resign(in ObjName myself);void send(in Message msg);void receive(out Message msg,

in ObjName myself);void ~aituntil(out Message msg,

in ObjName myself,in WaitCondition ~C);

void hold(in Time trn, in ObjName myself);Time no~();

};

Figure 4: Interface Definition (DESFacility.idl)

A CORBA Facility for Netlvork SiInulation 617

Object Definition. Operations role, enroll,and resign are used to define participating simula­tion objects, and to demarcate their beginning andending of execution.

Inter-Object Communication. Objects com­municate with each other using buffered message­passing (asynchronous communication), where everyobject has a unique message-buffer. An object sendsa message to another by invoking a send operation.Each message, with structure defined by Message,contains sender, receiver, message type, and messagecontents information. A message is deposited in themessage-buffer of its destination object on the invo­cation of a send operation, and carries a timestampwhich corresponds to the simulation time at whichthe corresponding send operation is invoked. An ob­ject accepts messages from its message buffer by in­voking a waituntil operation. The waituntil op­eration takes a sequence of wait-condition items asan input argument to determine which message willbe accepted by the object. Each wait-condition itenlspecifies a message-type, say mi and a boolean value,say bi , which is said to be enabled if the message buffercontains a message of type mi and bi is true, and miis called an enabling message. The enabling messagewith the earliest timestamp is removed and deliveredto the object. If all wait-condition items are disabled,the object is suspended for a maximum duration ofsim'ulation time equal to durat ion of a wait-conditionitem with msg_type equal to timeout. If omitted, adefault wait-condition item with msg_type equal totimeout is set with an arbitrarily large durationvalue. If no enabling message is received in theduration interval, the object is sent a timeout mes­sage. An object must accept a timeout message thatis sent to it. A separate receive operation is also pro­vided to accept the message with the earliest times­tamp from the message-buffer, regardless of its mes­sage type. It will block the invoking object until amessage is available.

Event Scheduling. The hold operation enablesthe invoking object to schedule a timeout message fordelivery to itself tm time units from now. It is usedto specify the simulation time used by a simulationstep. The now operation lets the invoking object toread the current value of the simulation clock.

5 PROTOTYPE IMPLEMENTATION

In this section, we describe a C++ implementation ofthe simulation facility in a multi-threaded version ofthe commercial ORB Orbix (IONA 1995). (Orbix isa Registered Trademark of IONA Technologies Ltd.)

We adopt the wait-until simulation algorithm

clock = 0;Initialize event-list;while (execution not terminated) do{ fetch next tuple (l1li' Si, di , ti) from event-list;

if (mi is not accepted by di ) thenstore mi in tem.p_queue;

else{ if (mi is a tinleout message) then clock = ti;

deliver 1ni to di for sinlulation;merge tem.p_queue with event-list;

}}

Figure 5: Wait-lTntil Sinlulation Algorithm

(Franta 1977), as shown in Figure 5, to inlplementthe simulation engine, in which an object lnay delayacceptance of a message based on its state such thatmessages are not necessarily delivered in the partialorder specified by the event-list. Each 10 may specifya wait-condition which restricts the types of nlessagethat it is willing to receive; a nlessage is delivered tothe destination 10 only if it satisfies its wait-condition.The sinlulation clock is advanced through the times­tamps associated with the tilneout messages in theevent-list.

In the C++ inlplementation, the DESFacility in­terface is implemented as the DESFacility -.i C++object (Figure 6) exporting the defined operations.Upon receiving an invocation for operation send, theDESFacility -.i object inserts the message into theevent list according to increasing timestamp order.On receiving an invocation for operations waituntiland receive, a thread is created implicitly to checkif there is any enabling message. It will block theinvoking object in case there is no enabling message.Finally, upon receiving an invocation for operationhold, a thread is created implicitly to first deposit atimeout message in the event list. It then block untilthe scheduled tinleout message becomes deliverable.

As simulation facility is defined in CORBA IDL, itdoes not dictate its implementation. The simulationfacility could very well be implemented using a paral­lel simulation algorithm to take advantage of parallelprocessing environment. With respect to its clients,the implementation is totally transparent, except forpotential performance improvement.

6 AN EXAMPLE

As an example, we consider the sin1ulation of abounded-buffer producer-consum.er system (Bagrodiaand Shen 1991). The consumer object repeatedly re-

618

#include "DESFacility.hh"

Shen

main (int argc, char **argv){

};

class DESFacility_i :public virtual DESFacilityBOAImpl

{

private:void enqueue(const struct Message& msg,

Time tstamp);public:

Time sim_clock; II sim clockstruct Event eventList; II event listDESFacility_i(char *marker); II constructorvirtual -DESFacility_i(); II destructorvirtual void role(const ObjName myself);virtual void enroll(const ObjName myself);virtual void resign(const ObjName myself);virtual void send(const Message& msg);virtual void reeeive(Message& msg,

eonst ObjName myself);virtual void waituntil(Message& msg,

eonst ObjNarne myself,eonst WaitCondition& we)

virtual void hold(Time tm,const ObjNarne myself);

virtual Time now();

struct Event {MessageTimestruct Eventstruct Event

};

msg;tstamp;*lst;*nxt;

DESFacility *p;Message msg_s, msg_r;int i, n, now, t_wait;p = DESFacility: :_bind("sim:simSrv", "");p->enroll("producer");now = t_wait = 0; n = Q_LENGTH;msg_s.source = new char[20];strepy(msg_s.source, "producer");msg_s.sink = new char[20];strcpy(msg_s.sink, "buffer");msg_s.msg_type = new char[20];strepy(msg_s .msg_type, "data");for (i = 0; i < MAX_ITEM; i++) {

if (n == 0) {now = p->now();p->receive(msg_r, "producer");n++; t_wait += p->now() - now;

}

p->hold(rand()%MAXPRODUCE, "producer");n--; p->send(msg_s);

}

now = p->now();printf("Producer utilization == %f\n",

«float)(now - t_wait)/(float) now));p->resign("producer"); p->_release();

}

Figure 7: The Producer Code

7 CONCLUSION

Figure 6: DESFacility C++ Inlplenlentation Class

quests a data item from the buffer using a requestmessage, waits to receive a data nlessage, and invokesa hold operation to simulate data consumption. Theproducer object waits to receive a free message fromthe buffer which indicates that the buffer has a freeslot, invokes a hold operation to simulate the gener­ation of a data item, and sends the itenl to the buffervia a data message. The buffer object repeatedly in­vokes a waitunt il operation that accepts a requestn1essage only when it is not enlpty and a data if it isnot full.

Figures 7, 8, and 9 list the C++ source code forthe producer, consumer, and buffer object, respec­tively, and Figure 10 depicts their interaction withthe DESFacility object to obtain the discrete-eventsinlulation service.

At the time when the computing industry is de­manding portable and interoperable distributed ap­plications, of which simulation is a notable example,CORBA has emerged as a de facto standard for dis­tributed object computing. A CORBA-compliant ob­ject request broker serves as a software bus to facili­tate communication among distributed objects, inde­pendently of their languages, operating systems, orhardware platforms. In addition, the OMA has de­picted a reference model where application-specificservices are provided as Common Facilities.

The paper describes a CORBA discrete-event sim­ulation facility. The facility exports an interface,defined in CORBA IDL, consisting of model defini­tion operations, and implements the interface using adiscrete-event simulation algorithm.

The main thrust of the paper is not to proposea new simulation language or a more efficient par­allel simulation algorithm, but to introduce a newparadigm for facilitating discrete-event simulation us-

A CORBA Facili(y for Net,,,ork Simulation 619

main (int argc, char **argv){

DESFacility *c;Message msg_s, msg_r;int i, t, t_used, now;c = DESFacility: : _bind(" sim: simSrv" ,,~,);

c->enroll("consumer"); ,now = t_used = 0;msg_s.source = new char[20];strcpy(msg_s.source, "consumer");msg_s.sink = new char[20];strcpy(msg_s.source, "buffer");msg_s.msg_type = new char [20] ;strcpy(msg_s.source, "request");for (i = 0; i < MAX_ITEM; i++) {

c->send(msg_s);c->receive(msg_r, "consumer");t_used += (t = randC) % MAXCONSUME);c->hold(t, "consumer");

}

now = c->now();printf("Consumer utilization == %f\n",

C(float)(t_used) / (float)now»;c->resignC"consumer"); c->_release();

}

Figure 8: The Consumer Code

ing the newly emerged CORBA technology and tomotivate more research activities and product devel­opment in this direction.

ACKNOWLEDGMENTS

This research was funded by the Arn1Y Research Lab­oratory under Cooperative Agreement No. DAALOl­96-2-0002."

REFERENCES

Bagrodia, R. L., K. M. Chandy, and J. Misra. 1987.A message-based approach to discrete-event simu­lation. IEEE Transactions on Software Engineer­ing 13(6):654-665.

Bagrodia, R. L. and C.-C. Shen. 1991. MIDAS: In­tegrated design and simulation of distributed sys­tems. IEEE Transactions on Software Engineering17( 10): 1042-1058.

Franta, W. R. 1977. The process view of simulation.New York: Elsevier North-Holland Inc.

IONA. 1995. Orbix: Programmer's Guide. laNATechnologies Ltd.

Martin, J. 1\11. and R. L. Bagrodia. 1995. COl\tl­POSE: An object-oriented environn1ent for par­allel discrete-event simulation. In Proceedings ofthe 1995 Winter Sim'u/ation Conference. 163-166,Washington, DC.

Misra, J. 1986. Distributed discrete-event simulation.Computing Survey 18(1):39-65.

OMG. 1992. Object Managem.ent Architecture Guide.Object Management Group and X/Open.

OMG. 1993. The Common Object Request Broker:Architecture and Specification. Object Manage­ment Group and X/Open.

AUTHOR BIOGRAPHY

CHIEN·CHUNG SHEN is a Member of Techni­cal Staff in Bellcore Applied Research. He receivedB.S. and M.S. degrees in computer science from Na­tional Chiao Tung University, Taiwan, in 1982 and1984, respectively, and a Ph.D. degree in con1puterscience from UCLA in 1992. His research interestsinclude distributed network control and o1anagementfor SONET, ATM, WDrvl and wireless networks, dis­tributed object computing, and network simulation.

620 Shen

main (int argc, char **argv){

Figure 10: Prototype Implementation

data

request

DESFacility,.",.---- .......,

~ ~simulation',,/ "V Clock \

, Event List ,

\~latiOn~1, .... Engine) ~~,........ *,tI'

free

data

DESFacility *b;Message msg_s_p, msg_s_c, msg_r;WaitCondition wc;int q, i, v, tstart, tend;b = DESFacility: :_bind("sim:simSrv", "");b->enroll("buffer"); tstart = b->now();msg_s_p.souree = new char[20];strcpy(msg_s_p.source, "buffer");msg_s_p.sink = new char[20];strcpy(msg_s_p.sink, "producer");msg_s_p.msg_type = new char[20];strcpy(msg_s_p.msg_type, "free");msg_s_c.souree = new char[20];strcpy(msg_s_c. source, "buffer");msg_s_c.sink = new char[20];strcpy(msg_s_c. sink, "consumer·');msg_s_c.msg_type = new char[20];strepy(msg_s_c.msg_type, ·'data");we._length = 2; wc._maximum = 2;wc._buffer = new WCltem[2];wc._buffer[O].msg_type = new char[20];strepy(wc._buffer[O].msg_type, "data");we._buffer[1] .msg_type = new char[20];strcpy(we._buffer[1] .msg_type, "request");for (i = q = v = 0;;) {

wc._buffer[O] .bguard = (q < Q_LENGTH);wc._buffer[1] .bguard = (q > 0);b->waituntil(msg_r, "buffer", we);if (strcmp(msg_r.msg_type, "data") == 0) {

tend = b->now(); v += q*(tend-tstart);tstart = tend; q++; break;

} else { II "request"b->send(msg_s_e); tend = b->now();v += q*(tend-tstart); tstart=tend; q--;if «++i) < MAX_ITEM)

b->send(msg_s_p);else

break;}

}

printf("The avg # of items in buf: %f\n" ,(float) v I (float) b->now(»;

b->resign("buffer"); b->_release();}

Figure 9: The Buffer Code