1CS514: Intermediate Course in Operating SystemsProfessor Ken BirmanVivek Vishnumurthy: TAApplications of these ideas Over the past three weeks we’ve heard about group communication Process groups Membership tracking and reporting “new views” Reliable multicast, ordered in various ways Dynamic uniformity (safety), quorum protocols So we know how to build group multicast…but what good are these things?Applications of these ideas Today, we’ll review some practical applications of the mechanisms we’ve studied Each is representative of a class Goal is to illustrate the wide scope of these mechanisms, their power, and the ways you might use them in your own workSpecific topics we’ll cover Wrappers and Toolkits Distributed Program-ming Languages Wrapping a Simple RPC server Wrapping a Web Site Hardening Other Aspects of the Web Unbreakable Stream Connections Reliable Distributed Shared MemoryWhat should the user “see”? Presentation of group communication tools to end users has been a controversial topic for decades! Some schools of thought: Direct interface for creating and using groups Hide in a familiar abstraction like publish-subscribe or Windows event notification Use inside something else, like a cluster mgt. platform a new programming language Each approach has pros and consToolkits Most systems that offer group communication directly have toolkit interfaces User sees a library with various calls and callbacks These are organized into “tools”2Style of coding? User writes a program in Java, C, C++, C#... The program declares “handlers” for events like new views, arriving messages Then it joins groups and can send/receive multicasts Normally, it would also use threads to interact with users via a GUI or do other useful thingsToolkit approach: Isis Join a group, state transfer:Gid = pg_join(“group-name”,PG_INIT, init_func, PG_NEWVIEW, got_newview,XFER_IN, rcv_state, XFER_OUT, snd_state, … 0); Multicast to a group:nr = abcast(gid, REQ, “%s,%d”, “a string”, 1234, ALL, “%f”, &fltvec); Register a callback handler for incoming messagesisis_entry(REQ, got_msg); Receive a multicast:void got_msg(message *mp) {Msg_scan(“%s,%d”, &astring, &anint);Reply(mp, “%f”, 123.45);}A group is created when a join is first issued. In this case the group initializer function is called. The user needs to code that function. Here the “new view” function, also supplied by the user, gets called when the group membership changes If the group already exists, a leader is automatically selected and its XFER_OUT routine is called. It calls xfer_out repeatedly to send state. Each call results in a message delivered to the XFER_IN routine, which extracts the state from the message To send a multicast (here, a totally ordered one), you specify the group identifier from a join or lookup, a request code (an integer), and then the message. This multicast builds a message using a C-style format string. This abcast wants a reply from all members; the replies are floating point numbers and the set of replies is stored in a vector specified by the caller. Abcast tells the caller how many replies it actually got (nr)This is how an application registers a callback handler. In this case the application is saying that messages with the specified request code should be passed to the procedure “got_msg”Here’s got_msg. It gets invoked when a multicast arrived with the matching request code. This particular procedure extracts a string and an integer from the message and sends a reply. Abcast will collect all of those replies into a vector, set the caller’s pointer to point to that vector, and return the number of replies it received (namely, the number of members in the current view)Threading A tricky topic in Isis The user needs threads, e.g. to deal with I/O from the client while also listening for incoming messages, or to accept new requests while waiting for replies to an RPC or multicast But the user also needs to know that messages and new views are delivered in order, hence concurrent threads pose issues Solution? Isis acts like a “monitor” with threads, but running them one at a time unless the user explicitly “exits” the monitorA tricky model to work with! We have… Threads, which many people find tricky Virtual synchrony, including choices of ordering A new distributed “abstraction” (groups) Developers will be making lots of choices, some with big performance implications, and this is a negativeExamples of tools in toolkit Group join, state xfer Leader selection Holding a “token” Checkpointing a group Data replication Locking Primary-backup Load-balancing Distributed snapshotHow toolkits work They offer a programmer API More procedures, e.g. Create_replicated_data(“name”, type) Lock_replica(“name”) Update_replica(“name”, value) V = (type)Read_replica(“name”) Internally, these use groups & multicast Perhaps, asynchronous cbcast as discussed last week… Toolkit builder optimizes extensively, etc…3How programmers use toolkits Two main styles Replicating a data structure For example, “air traffic sector D-5” Consists of all the data associated with that structure… could be quite elaborate Processes sharing the structure could be very different (maybe not even the same language) Replicating a service For high availability, load-balancingExperience is mixed…. Note that many systems use group communication but don’t offer “toolkits” to developers/end users Major toolkit successes include New York and Swiss Stock Exchange, French Air Traffic Control System, US AEGIS warship, various VLSI Fab systems, etc But building them demanded special programmer expertise and knowledge of a large, complex platform Not every tool works in every situation! Performance surprises & idiosyncratic behavior common. Toolkits never caught on the way that transactions became standard But there are several popular toolkits, like JGroups, Spread and Ensemble. Many people do use themLeads to notion of “wrappers” Suppose that we could have a magic wand and wave it at some system component “Replicatum transparentus!” Could we “automate” the use of tools and hide the details from
View Full Document