USENIX ANNUAL conference TECHNICAL reports · 2019. 2. 25. · Novell was able to do ver y well...

conferencereports

U S E N I X A N N UA LTE C H N I C A LCO N F E R E N C E( U S E N I X ’ 0 4 )Boston, MassachusettsJune 27–July 2, 2004

P L E N A RY S E S S I O N

Summarized by Richard S. Cox

Open Source and Proprietary Soft-ware: A Blending of Cultures

Alan Nugent, Novell

Alan Nugent opened the USENIXAnnual Technical Conference withhis plenary session addressing theintegration of open source softwareand procedures at Novell.

Many people believe that opensource will destroy the softwareindustry; that it is developed byhackers without discipline; that itis a fad; or that there is no moneyin open source. Seeking to debunkthese myths, Alan first suggestedthat, rather than wrecking theindustry, open source has increaseddiversity and thus has createdopportunities. Second, open sourcesoftware can be of very high quality,since a majority of open sourcecontributors are professional devel-opers working on projects thatinterest them. The community isgrowing daily, and contributors arequick to realize important initia-tives. While open source software isfree, there is a market for sellingthe support and maintenance con-tracts that large customers requirebefore they are willing to buildmission-critical systems using apackage.

The adoption of open source hasallowed Novell to work with cus-tomers to build solutions that moreclosely match their needs and infra-

structure. Novell does this by pro-viding complementary packages(open or closed) that interact withthose developed by the open sourcecommunity. By focusing on com-plementing existing projects, ratherthan providing substitutes, theyavoid competing with open sourcedevelopers, an arrangement thatbenefits all involved.

At Novell, this has requiredreworking the legal frameworkunder which licenses are sold,expending significant effort in con-vincing customers to accept solu-tions combining proprietary andopen components, and changingthe focus of the organization.

Greg Mitchell asked how the soci-ology of the company changed asmore open source developers werebrought in. Alan responded that,while some employees were upsetand a few even left, the acquisitionof open source teams has been verysuccessful and brought moreenergy throughout the company.Novell was able to do very wellretaining employees from acquiredcompanies.

G E N E R A L S E S S I O N PA P E R S :I N STR U M E NTATI O N A N D D E B U G G I N G O O O O O O O

Summarized by Swaroop Sridhar

Making the “Box” Transparent:System Call Performance as aFirst-Class Result

Yaoping Ruan and Vivek Pai, Prince-ton University

Mr. Yaoping Ruan presented the“DeBox”ing technique for debug-ging OS-intensive applications. Hebegan the talk with a motivatingexample of monitoring system callperformance on a server runningthe SpecWeb99 benchmark. Hepointed out that system call profileas measured from user space some-times indicated anomalous kernelbehavior. He identified the trade-offbetween speed, completeness, andaccuracy among various profilingtools. Later, Ruan presented the

; LO G I N : O C TO B E R 2 0 0 4 U S E N I X ’ 0 4 A N N UA L TE C H N I C A L CO N F E R E N C E 41

This issue’s reportsfocus on the USENIXAnnual TechnicalConference (USENIX’04), held in Boston,Massachusetts,June 27–July 2, 2004.Our thanks to thescribe coordinator:

Rik FarrowOur thanks to thesummarizers:

Bill BogstadMing ChowBrian CornellRichard S. CoxTodd DeshanePatty JablonskiRob MartinMartin MichlmayAdam S. MoskowitzPeter NilssonG. Jason PengCalicrates PolicroniadesDavid RevemanMatt SalterSwaroop SridharSudarshan SrinivasanMatus TelgarskyWanghong YuanNingning Zhu

design of the DeBox system. Thekey idea is to make the system callperformance a first-class result andreturn it in-band (like errno).Proposing a split between themeasurement policy and mecha-nism, Ruan said that the applica-tions should be able to interactivelyprofile interesting events.

Later, Ruan gave details about theimplementation of DeBox. He gavethe details of profiling primitivesadded to the kernel and the inter-face available to the applications.He also provided details about thevarious kinds of information thatthe system offered, the amount ofchange that had to be done to thekernel and applications, and so on.Ruan went on to present a casestudy on Flash Web server per-formance. He presented variousoptimizations with a step-by-stepperformance analysis.

Ruan concluded by stating thatDeBox is very effective on OS-intensive applications and complexworkloads. He also claimed that theresults showed that the system wasportable. During the Q&A session,Ruan said that they were investigat-ing the use of DeBox on other OS-intensive applications such as data-base systems, but the results werenot yet available. More informationabout DeBox can be found athttp://www.cs.princeton.edu/~yruan/debox, or by contacting {yruan,vivek}@cs.princeton.edu.

Dynamic Instrumentation of Pro-duction Systems

Bryan M. Cantrill, Michael W.Shapiro, and Adam H. Leventhal, SunMicrosystems

In introducing Bryan Cantrill, ses-sion chair Val Henson—also fromSun Microsystems—said that shecould definitely confirm Sun’s useof DTrace in production. Cantrillbegan his power-packed speech bystating that all of today’s tools weretargeted at development and notproduction. As a result, the systemsare incapable of dealing with sys-temic problems. Cantrill asserted

that for a tool to be used in produc-tion, the necessary constraints arethat there should be zero probeeffect when disabled, and the sys-tem must be absolutely safe. Tohave systemic scope, both kerneland applications must be instru-mentable, and the system must beable to prune and coalesce theenormous amount of data into use-ful information.

Later, Cantrill introduced the vari-ous concepts and features ofDTrace: dynamic-only instrumenta-tion, unified instrumentation, arbi-trary context kernel instrumenta-tion, high-level control language,predicate and arbitrary action spec-ification, data-integrity constraints,facility for user-defined variables,data aggregation, speculative trac-ing, scripting capacity, boot-timetracing, virtualized consumers, etc.Next, Cantrill elaborated on the Dlanguage: syntax and use, D inter-mediate form, probes, providersand actions, aggregations and scala-bility of the architecture. Cantrillalso shared some experiences withDTrace and gave some examples ofD scripts and analyzed their results.Finally, using the example of a bugin gtik2 applet2—a stock ticker forGNOME desktop—he showed howa small programmer error couldcause widespread damage in a pro-duction system such as SunRayserver. Cantrill challenged the ideathat no other existing tool couldtrace this problem to its root cause,and that a trace was possible onlyby the extensive use of aggregationfunctions and thread local variablesprovided by DTrace.

During the Q&A session, JonathanShapiro said that he believed thatthe gtik2 applet2 problem shouldbe attributed to the fundamentalproblems in monolithic kerneldesign, and asked the speaker tocomment on the use of DTrace fordebugging kernel bugs. Cantrill didnot totally agree with Shapiro’sviews, but only asserted thatDTrace was effective in tracing ker-nel-level bugs. Answering another

question, Cantrill said that therewas no extra effort required to usethis tool with third-party kernel-level modules. When askedwhether there were any plans toport their system to Linux or anyother operating system, Cantrillanswered in the negative andquipped, “Use the best OS avail-able!” The authors can be con-tacted at [email protected].

Flashback: A Lightweight Exten-sion for Rollback and Determinis-tic Replay for Software Debugging

Sudarshan M. Srinivasan, SrikanthKandula, Christopher R. Andrews,and Yuanyuan Zhou, University ofIllinois, Urbana-Champaign

With the increase in volume andcomplexity of software develop-ment, there is a proportionalincrease in software bugs, theireffects, and the difficulty in tracingor even reproducing them. Variouscheckpointing and logging mecha-nisms and their applications havereceived a lot of research attentionin the last decade. Mr. SudarshanSrinivasan presented Flashback, alightweight OS extension to facili-tate rollback and replay, as appliedto software debugging.

After providing a brief generalbackground and motivation forlightweight checkpointing, Srini-vasan went straight into the mainidea of Flashback. Flashbackachieves checkpointing by forkinga shadow process, thus replicatingthe in-memory state of the process.The processes’ interactions with thesystem are logged so that, duringreplay from a checkpoint, the(shadow) process gets an executionenvironment similar to the originalrun. Srinivasan presented somechallenges posed due to multi-threading, memory-mapped files,and shared memory and signals. Healso presented the approachesadopted in Flashback towardsolving these problems.

Srinivasan went on to present somedetails of the present Linux imple-

42 ; L O G I N : V O L . 2 9 , N O . 5

mentation regarding modificationsto the kernel, changes to GDB, etc.Srinivasan identified incorporatingreplay support for multi-threadedapplications as an area for futurework. Later, responding to Val Hen-son’s question regarding possibleapplications of Flashback otherthan debugging, Srinivasan saidthey were investigating uses ofFlashback in other avenues, such aslightweight transaction models.The source code for Flashback canbe obtained at http://carmen.cs.uiuc.edu/.

A DVA N C E D SYSTE M O OO OOA DM I N I STR ATI O N S I G :AUTOM ATI N G SYSTE M A N DSTO R AG E CO N F I G U R ATI O N

Summarized by Rob Martin

The CHAMPS System: A Schedule-Optimized Change Manager

Alexander Keller, IBM T.J. WatsonResearch Center

Dr. Alexander Keller began bydescribing CHAMPS (Change Man-agement with Planning and Sched-uling) as “a schedule optimizedchange management system” that isnot yet a product. “It’s a researchprototype [providing] change man-agement with planning and sched-uling.” Its end product is theschedule: “all the things that aregoing to be carried out on whichmachines [and] concrete systemsthat are going to carry out thesetasks.” Keller described this as “achange plan.”

Keller described CHAMPS withinthe larger context of change man-agement as “trying to assess theimpact of a change and figure outwhat the dependencies betweendifferent tasks are and creating achange plan. . . . We are specificallynot concerned with actually imple-menting or rolling out a change,because there are deployment sys-tems that can do this.” Later in thetalk, Keller gave examples of suchsystems: cfengine and Tivoli Intelli-

gent Orchestrator for Service Opti-mization.

The CHAMPS system consists of twosubcomponents: the Task Graph Builderand the Planner and Scheduler. The endproduct of the system is a change plandepicted in a standard workflow lan-guage (BPEL4WS). This, in turn, is fedinto an “off-the-shelf” deployment sys-tem which “rolls out the changes andprovides feedback status informationback into the [CHAMPS] system forsummary planning.” The workflowengine executes the plan and monitorswhether each activity has completed orfailed.

A key goal of CHAMPS is optimiz-ing the schedule based on depend-encies to carry out tasks in parallelwherever possible. The informationused to figure out which tasks aregoing to be carried out in sequenceand which in parallel are “productdependency descriptions.” “Theavailability of authoritative depend-ency information [from packagedevelopers] is very important.”Once the dependencies are put intothe Task Graph Builder, the systemgenerates the Task Graph.

“The Task Graph tells us whichtasks are going to be carried out, inwhat order . . . , and whether theymust be in sequence or can be inparallel.” The Task Graph is used asinput to the Planner and Scheduler.“The Planning system may makedecisions such as ‘we must takeaway a machine from customer Xand give it to customer Y’; in orderto do that [the system] must beaware of the service level agree-ments and policies that the datacenter has. . . . It is up to the plan-ning system to bind the existingTask Graph to the complete systemto generate concrete system names,times, and dates.

“We put in declarative informationabout the relationships betweentasks, [and the CHAMPS system]automatically generates this sched-ule and allows the administrator toapply modifications to the sched-

ule.” Estimating individual taskduration is crucial, and CHAMPSuses “past deployments” to calcu-late future durations for individualtasks.

Multiple task graphs, each repre-senting a single change, are inputinto the Planner and Scheduler,which then binds the changes toservices and resources and opti-mizes a schedule for all of thechanges. “We are treating this prob-lem as an optimization problem.”The optimization is done by “fiftypages of Java . . . not visible to theadministrator. We support a verygeneral level of objective functions[for] minimizing penalties, maxi-mizing profits. The administratorselects from push-button optionsthat provide choices like ‘maximizeprofits,’ ‘minimize downtime,’‘maximize throughput,’ ‘minimizecosts.’ By selecting one [or a combi-nation] of these choices the opti-mization parameters are automati-cally set.” The CHAMPS systemthen calculates the optimum sched-ule, if necessary deciding that cer-tain changes cannot be accom-plished given the overall set ofchanges requested.

Keller concluded by listing theareas that require more work in thefuture, including “tooling fordeployment descriptors,” reusingchange plans (storing them in anXML library, for example), know-ing when a plan is running behindschedule, carrying configurationinformation along with the work-flows, and identifying parametersthat flow out of one task and arerequired for other downstreamtasks.

During the Q&A session, there wasa lively exchange on the “sad stateof dependencies in software pack-ages.” Is there a standard fordescribing dependencies? Workdone by the Grid Forum on defin-ing a standard, and the use ofdependency sniffing tools werementioned.


Autonomics in System Configura-tion

Paul Anderson, University of Edin-burgh

What is system configuration? PaulAnderson, professor and researcherat the University of Edinburgh,starts out with some backgroundon the general subject. When youwant to build a new site, you startoff with three things: the hardware(empty disks and bare metal), thesoftware, and specifications andpolicies about how you want thefinal system to run. The core of theconfiguration problem is to takethose three things and put themtogether to get some sort of com-puter system that performs to thespecification. Anderson refers tothe final site as a “fabric,” a term heborrows from the recent work ingrid computing.

Anderson points out that the “mainthing to notice is the big distinctionbetween the software and the con-figuration policies. The pile of soft-ware you start off with has no con-figuration and in theory can all beput on all the machines that you’vegot. It’s the specifications and theconfiguration policies that differen-tiate the individual machines.”

Configuration starts with the baselayer of internal services insideyour fabric at a lower level than theapplications you want to end upwith. DNS, NFS, DHCP, and likeservices form a base layer you haveto get going before you build any-thing on top of it.

The idea of autonomics is to “takesome of the low-level decisionmaking away from the systemadministrator and have a lot ofthings happen automatically, so thesystem administrator can move upa level and think of higher-levelpolicies and planning.” As with acompiler, you trust the autonomicsystem to place low-level data anddecide which bits go where.

After the initial configuration, aschange occurs due to load balanc-ing, software or hardware failure,

and day-to-day use, the autonomicsystem adjusts the fabric and con-figuration of the system so that itcomes back into alignment withthe original specifications and poli-cies. The feedback from the auto-nomic system does not makechanges to the original specifica-tion; rather, it brings the fabricback to providing the original serv-ices and policies specified.

“Autonomics is not new. Cfengineand lcfg are examples of tools thatprovide this sort of automatic fix-ing up of configuration files whensomething goes wrong at the hostlevel. There are inter-host auto-nomic systems like fault-tolerancesystems, RAID, and load balancingthat will adjust systems. What isnew is trying to think of this in auniform way and integrating it intothe configuration system.”

Anderson described the majorissues under consideration inresearching autonomic solutions.He described “a declarative specifi-cation of what the system behaviorshould look like. Some kind of log-ical statement that is true about thesystem rather than a recipe abouthow to get there. If you don’t have agood declarative statement to startwith, then you don’t know what todo. . . . The language you need todescribe the configuration is not aprogramming language: We are nottalking about a process, we are talk-ing about the description of theconfiguration data and the way thatthat system actually is.” Andersongives an example of a declarativestatement. “‘Host X uses host M asa mail server.’ In most configura-tion systems you don’t see state-ments like these. Rather, you seelower-level details, like a script set-ting parameters for sendmail.cf.”

The goal is to use the declarativelanguage to describe the systemand “let the autonomic system jug-gle the details” to make sure thespecifications remain true.

An example declaration: “Makesure we have two DHCP servers on

each network segment.” Thisexpresses a high-level policy ratherthan details like “make thismachine configured as a DHCPserver.” The final goal of an auto-nomic system is to take thesedeclarative statements and generatethe details. “System administratorswill specify those criteria that areimportant for the job without spec-ifying the details. The importantpoint is not to specify too muchdetail, because you need to give theautonomic system room to move.”If something breaks, the autonomicsystem needs flexibility in order tofix the problem.

Autonomic systems require a lot oftrust in the system. The systemautomatically makes some seriousdecisions for you. “System admin-istrators are not normally happygiving that kind of freedom to thesystem. You want the system todecide things for you but you wantto be able to review them andadjust them to make sure they areright.” Autonomic systems willneed to provide feedback as to whysomething has happened. “Youshould be able to ask the system,‘Why have you put that there?’”Some mechanism for reviewing sys-tem actions and tuning the policyimplementation for future actionsneeds to be provided.

What Anderson is seeking is a com-promise between the two extremesof, on the one hand, a completeexpert system that can be givenhigh-level policy goals and performall reasoning and logic decisions,generating all individual assign-ments for all machines and serv-ices, and a solution that is based onhand-crafting (or scripting) thelow-level specifications formachines and services required todeliver the specified policy. Whatwe want is some autonomics butnot a completely unpredictable sys-tem.

“The autonomic system has to beable to change all aspects of a sys-tem configuration dynamically.UNIX was never designed to be re-

44 ; L O G I N : V O L . 2 9 , N O . 5

configured on the fly.” UNIX has allsorts of config files in all sorts offormats; services may need to bestopped and re-started in order tomake certain changes. “This is a bigproblem in incorporating autonom-ics into system configuration.”

Anderson concluded by reviewingthe lcfg system, analyzing where ithas useful autonomic capabilitiesand where it falls short. He pointedto the http://www.lcfg.org Web siteand the LISA ’03 Gridweaver paperfor those who want to explore thecomplete details.

G E N E R A L S E S S I O N PA P E R S : O SW I M M I N G I N A S E A O F DATA

Summarized by G. Jason Pengand Wanghong Yuan

Email Prioritization: ReducingDelays on Legitimate Mail Causedby Junk Mail

Dan Twining, Matthew M.Williamson, Miranda J.F. Mowbray,and Maher Rahmouni, Hewlett-Packard Labs

Matthew Williamson discussed themotivation for this paper. In partic-ular, he described the delay prob-lem caused by junk emails, the dis-tribution of junk mails, and thesource of junk mails. Dan Twiningthen presented the proposedapproach, which combines pre-acceptance (header scanning) andpost-acceptance (content scanning)to predict the next message typebased on sending history. The pre-acceptance method maintains thenumber of good and total messagesand tells if a server is good basedon the ratio. The system is imple-mented in a lightweight mannerand shows good results on a realsystem.

Redundancy Elimination WithinLarge Collections of Files

Purushottam Kulkarni, University ofMassachusetts; Fred Douglis, JasonLaVoie, and John M. Tracey, IBM T.J.Watson Research Center

Storage needs keep growing as per-byte cost gets cheaper. The goal instorage is to increase efficiency byreducing redundancy. Current tech-niques (compression, duplicateblock-and-chunk suppression, andresemblance detection) have short-comings. Purushottam Kulkarniproposed a technique calledRedundancy Elimination at BlockLevel (REBL), which first detectsduplicate chunks and encodesblocks using the resemblance tech-nique. This paper also evaluatesfive techniques to quantify theeffectiveness of REBL.

Alternatives for Detecting Redun-dancy in Storage Systems Data

Calicrates Policroniades and IanPratt, Cambridge University

Calicrates Policroniades introducedthe benefits of redundancy elimina-tion and previous techniques forredundancy elimination, and thencompared three frequently usedtechniques: whole-file contenthashing (WF), fixed-size blocking(FSB), and content-defined chunks(CDC). The results show that interms of compression ratio, CDC isthe best, FSB is almost as good, andWF is the worst. But when com-pression, processing overhead, andstorage overhead are considered,however, no one solution wins.

A DVA N C E D SYSTE M O OO O OA DM I N I STR ATI O N S I G :SYSTE M A DM I N I STR ATI O N :TH E B I G P I C T U R E O O O O O O

Summarized by Rob Martin

The Technical Big Picture

Alva Couch, Tufts University

Each fall at Tufts University, Profes-sor Alva Couch presents a talk tohis students on the Big Picture insystem administration. In Couch’swords, “Where are we going? Whatare we going to do? How is it goingto work? What is going to be thebenefit?” This year at USENIX Tech’04, Professor Couch let us in on apreview of his “technical briefing

on next year’s big picture” talk forhis students.

According to Couch, the future ofsystem administration is about“cost models” and “supporting theenterprise mission.” Couch sum-marized it this way: “Based upon acost model, we can re-define goodsystem administrating. That idea is rather cosmic, because what weare doing right now, what we con-sider ‘good’ right now, I wouldclaim does not make sense withrespect to any cost model. . . .Looking at things from a broaderperspective of lifecycle costs, weget a better idea of whether we aredoing our jobs.”

Professor Couch refers to tradi-tional SA thinking and practice as“micro-scale reasoning” and “thebottom-up approach.” He includes“adhering to practices, processmaturity, six nines at the server,closing tickets quickly, reducingtroubleshooting costs” as examplesof micro-scale thinking. The oppo-site of this is the “top-downapproach”: “In a top-downapproach we start at the organiza-tion and mission and work down.It turns out that starting at thatpoint and thinking out the wholenature of the profession leads todifferent conclusions and that’s thesubject of this talk today.”

Professor Couch lists some obser-vations drawn from “macro-scalethinking”: “System administrationenables particular things. It enablesmissions. It supports plans. It man-ages resources. It enforces policies.There is a very high level at which,Burgess says, ‘the system adminis-trator manages human computerecologies.’” Professor Couch saysthis macro-scale thinking will leadto some sacrilegious ideas. “Sixnines for the mission does notrequire six nines at the servers. . . .There is a fundamental idea that webuild six nine infrastructures uponsix nine servers and six nine foun-dations. That is actually not true.Meta-stability is enough. Perceivedstability is enough. Security that


compromises mission can be inap-propriate and counter-productive.Security is not an end unto itself. Itis part of a larger mission pictureand availability and security haveto be balanced.”

Three recent published papers that“got a lot of flak in the last LISAand LISAs before” got ProfessorCouch thinking this way. Thepapers were on the cost of down-time (Patterson); the timing ofsecurity patches (Beattie et al.);and. resource management withoutquotas for specific users (Burgess).

Patterson says downtime can bequantified. Professor Couch “can-not believe the resistance that thisidea got. Nobody ever talked aboutcost models before. And maybebecause of that this was a very con-troversial idea.”

Couch then talked about the paperthat “caused a riot.” “Beattie et al.showed that if uptime was impor-tant because downtime was expen-sive, then waiting a couple ofweeks to apply a new securitypatch was probably optimal. . . .The thinking was about a costmodel; it was not about simple reli-gion, about just applying thingsbecause you are supposed to, butabout understanding that patchesof a problem in the very first case . . .have problems themselves and thatwaiting a couple of weeks to applyall of them was a better enterprisestrategy.

“Finally, another very bizarre idea:protect useful work instead of lim-iting people. Burgess actually pro-poses a game theoretical approachfor quotas. The idea of the game isextremely simple. You have a verysimple strategy for deleting pigsand you counter every strategy theuser could use to defeat you. It usesrandom scheduling for cleanup tobeat the wily user.

“These three examples have com-mon attributes. They consider thebroader picture of enabling workand mission rather than fixing sys-tems. They consider costs and val-

ues rather than just considering thecost of implementing a change.They also include the cost of notdoing things, as well as the cost ofdoing things.”

Couch proposes that we have tochange the way we are doing SA:“In pursuing micro-scale perfectionwe are pursuing a private game,and nobody except us cares. Wehave to play a different game. . . .Micro-scale system administrationas we know it is doomed. The ideaof pursuing six nines at the serverwill be a solved problem in 10years.” He referred to the previousUSENIX Tech session on autonom-ics and said, “We are beginning tounderstand how to automateinstalls, automate deployments,and automate monitoring andrecovery. In the near future muchof this will be automated. Unfortu-nately, system administration issubject to outsourcing. . . . But wecan’t . . . automate macro-scalethinking. That’s the future of sys-tem administration. Being able totake these boxes with six nines andmake them talk to each other tosupport an enterprise mission.

“The future will be about under-standing cost and value and howthey relate. It’s going to be aboutinteracting with middleware. It’snot about supporting users; it’sabout supporting missions.”

Professor Couch says the new chal-lenge is to “take the human missionand turn it into something themachine can understand.” To dothis we will need to research newareas, such as economic models todescribe “making day-to-day cost-value decisions.” Professor Couchsuggests we need to ask, “How doesone best quantify the value of mis-sion support? How does SA workimpede or aid mission? Is anythingyou are doing getting in the way ofmission and how can you stop?”

He concluded by reminding uswhat can’t be automated and out-sourced in SA: “We are here at thisconference because one can’t out-

source community. Outsourcingaffects and limits many things. Onecannot outsource the value of peo-ple being together in one place andthinking about a common problem.That will remain a factor in systemadministration I think for as longas we live.”

G E N E R A L S E S S I O N PA P E R S :N E T WO R K P E R F O R M A N C E O

Summarized by SudarshanSrinivasan

Monkey See, Monkey Do: A Toolfor TCP Tracing and Replaying

Yu-Chung Cheng, Stefan Savage, andGeoffrey M. Voelker, University ofCalifornia, San Diego; Urs Hölzleand Neal Cardwell, Google

The authors describe Monkey See,Monkey Do (MS-MD), a tool thatgenerates realistic client requests inorder to test changes to the backend of Google search engines. Cur-rently, changes to servers are testedby either using synthetic (and con-sequently unrealistic) workloads orreal users, making it risky andeffort-consuming. The motivationfor developing MS-MD is to over-come the shortcomings of existingapproaches of testing.

The tool has two phases of opera-tion—the Monkey See phase,where it observes real network con-nections, measuring network trafficparameters along the way, and theMonkey Do phase, where it gener-ates realistic workloads based onthe previously observed metrics.The recorded parameters includethe HTTP header, query parame-ters, delay ACK policy, and othermeasurable quantities (such asresponse time). All tracing is donein front of the server farm, and theauthors assume that congestion—i.e., queueing of requests—hap-pens, if at all, only along the datapath. They also assume that theWeb servers themselves are wellprovisioned and that there is nocongestion in the intranet. Caching

46 ; L O G I N : V O L . 2 9 , N O . 5

behavior is also recorded andreplayed by MS-MD.

They evaluate the tool with respectto two questions: how accurately itreproduces the workload, and howaccurately it predicts server per-formance with changes effected.Results show that the measuredtimes without changes to the ker-nel match up more or less betweenthe original run and the simulationusing MS-MD. The tool is moreaccurate when the RTTs are small;they ascribe this behavior to thefact that the client emulators are on Linux systems, which have amore aggressive ACK policy thantraditional Windows clients. Exper-iments also show that the tool ac-curately predicts changes in net-work behavior when services arechanged. The tool works for Google,and the authors contend that it willalso be usable in other domains.

A Transport Layer Approach forImproving End-to-End Perfor-mance and Robustness UsingRedundant Paths

Ming Zhang, Junwen Lai, LarryPeterson, and Randolph Wang,Princeton University; Arvind Krish-namurthy, Yale University

Ming described mTCP, a transport-level network protocol developedby the authors for aggregating thebandwidth of multiple heteroge-neous paths between two hosts.Bandwidth aggregation providesthe benefits of improved perform-ance compared to individual net-work connections, while alsoimproving the resilience of theaggregate connection. The mainchallenges for providing effectivebandwidth aggregation are conges-tion control, congestion sharing,recovery from failed paths, andselecting which paths to use forpackets dynamically.

mTCP uses a single send/receivebuffer for all connections, alongwith per-path congestion control.Packets get striped across the vari-ous possible links. This leads to agreater chance of packets getting

reordered, though along each chan-nel packets are still in order. Thisgenerates too many DUP ACKS.The problem of packet reorderingis solved by using SACK TCP.mTCP uses an extended scoreboardalgorithm to figure out which pack-ets have been received and whichare outstanding. Packets are sent inthe order in which they are queued,and the choice of channel is basedon proportional scheduling.

For handling shared congestion,mTCP drops one or more of theshared connections in the presenceof congestion, so that single-chan-nel connections do not suffer at theexpense of aggregated connections.Shared connections are detected bystudying the correlations betweenthe different fast retransmissions—closely related fast retransmissionsbetween two links point to a sharedconnection. For path selection,overlay networks are used to createcandidate paths from which a sub-set of paths is selected greedily withthe minimum common linksbetween them. The greedy algo-rithm chooses paths that are mostdisjoint so that there is minimuminterference between the paths interms of performance impact andthe effect of failed links.

Performance measurements showthat the throughput of mTCP ismore or less cumulative of the indi-vidual network throughputs, as itshould ideally be. Separate per-pathcongestion control provides betterthroughput than combined control.The failure-detection and recoverymechanisms adopted by mTCPwork effectively, allowing the net-work to recover seamlessly fromthe failure of one or more of thelinks. Finally, the throughput of themTCP system is significantly betterthan individual paths in the pres-ence of congestion.

Multihoming Performance Bene-fits: An Experimental Evaluation ofPractical Enterprise Strategies

Aditya Akella and SrinivasanSeshan, Carnegie Mellon University;

Anees Shaikh, IBM T.J. WatsonResearch Center

Multihoming is a frequentlyadopted strategy in enterprise net-works for improving performanceas well as availability of the net-work. Route controllers are used toprovide the required performanceand availability characteristics.Aditya presented the results ofexperiments conducted by theauthors to evaluate the perform-ance benefits achievable from com-mercially available multihomingnetwork solutions. This workextends an earlier study, whichshowed potential performanceimprovements of up to 40% com-pared to no route control for athree-ISP network under idealroute control. Aditya also presenteda simple near-optimal greedy routecontrol algorithm.

The route controller needs to moni-tor performance on the ISP linksand choose the best link to sendpackets through based on the per-formance of the ISPs at that time. Italso needs a way to direct trafficonce this choice is made. Theauthors use EWMA (exponentialweighted moving average) to trackaverage performance of each of theISPs and decide on the best path.While redirecting outbound trafficalong a particular ISP’s network istrivial, redirecting incoming trafficis a little more difficult. In-boundtraffic from within the enterprise isredirected using NAT, and exter-nally originated traffic is handledby modifying the DNS entries.

While monitoring the ISP links’performance, only the traffic to thetop Web servers is observed, sincethey account for most of the net-work traffic. The actual monitoringcan be either passive or active. Inpassive measurement, the routecontroller periodically measuresthe turnaround time (time betweenthe last HTTP request and the firstresponse); this is an estimate of theRTT of the network link. Routecontrollers doing active monitoringinitiate out-of-band probes to get


network performance metrics. Slid-ing windows and frequency countsare two methods used to decide thefrequency of monitoring.

The performance measurementsshow that even simple passivemonitoring of the network connec-tions offers significant performancegains compared to no route control.Active monitoring outperformspassive monitoring, but only by asmall margin. The use of history inEWMA does not offer any perform-ance benefit; the current perform-ance of the network connections isa good indicator of future perform-ance. With regard to the effect ofthe frequency of sampling on per-formance, results show that a verysmall sampling interval is harmfulto the performance because of fre-quent changes to NAT and DNSentries, while a too-large samplinginterval may lead to stale valuesbeing used for the network metrics.

A DVA N C E D SYSTE M O OA DM I N I STR ATI O N S I G :L A RG E STO R AG E O O O O

Summarized by Adam S.Moskowitz

Autonomic Policy-Based StorageManagement

Kaladhar Voruganti, IBM AlmadenResearch

Kaladhar Voruganti discussed hiswork on the SMaestro NetworkStorage Planner, which is part ofIBM’s autonomic computing effort.Despite advances in technology,storage resources tend to be poorlyutilized, it is difficult to map appli-cation needs to storage systemsbased on their capabilities, and the number of system administra-tors needed to manage storage hasnot decreased (despite claims ofeasier configuration and manage-ment). Customers are moving toSAN and NAS solutions, but theseproblems are not going away. Voru-ganti believes that there are bothprocess and technological aspects

to the problems (and their solu-tions).

There is currently virtually noautomated solution to analyzing acustomer’s environment (withrespect to storage needs), no way totranslate high-level business goalsinto technology requirements andpolicies, no way to plan a storageinfrastructure based on these needsand requirements, and no way tomonitor the solution to ensure thatit does not violate the stated goalsand requirements. Voruganti’s workis limited to a tool to helping planthe storage infrastructure. He wasalso careful to note that this tool isintended to make things easier forthe architect, not replace him.There are many daunting tasks fac-ing an architect when planning astorage infrastructure: interoper-ability concerns, best practices tofollow, gathering data from multi-ple sources (all of which use differ-ent reporting mechanisms), per-forming complicated “what-if”analysis, and validating that every-thing was done correctly. SMaestrois intended to make at least some ofthis easier.

Typical application requirementsinclude I/Os per second (both aver-age and peak), bandwidth, percent-ages of random/sequential reads/writes, MTBF, maximum acceptableoutage times, encryption, integrity,wrote-once support, recoverability,retention times, scalability, and (ofcourse) cost. All this must be bal-anced against typical storage sys-tem capabilities such as latency, I/Orates, availability, points of failure,“hot upgrade,” reliability, and (hereit is again) cost. SMaestro uses tem-plates for both categories as well asfor virtualization software, backup/restore software, and SAN file sys-tems. Policies are written in plainEnglish and then translated, usingdata models, into something thatcan be used with the templates tosuggest a storage architecture andto verify that the proposed architec-ture meets the requirements.

Experiences with Large StorageEnvironments

Andrew Hume, AT&T Research

In his talk, subtitled “Inside aninode, no one can hear youscream,” Andrew Hume discussedhis experiences trying to actuallydeal with large quantities of data.How large? In one case his projectcollected between 200GB and700GB of new data every day.Hume was quick to point out that“20TB just doesn’t go as far as itused to.” Hume also mentionedimprovement in compression algo-rithms, some of which study thedata and then routinely deliverratios well above 90%. [Summa-rizer’s note: Some of these compres-sion programs were written byDave Korn; when I asked him ifthey would be released to the pub-lic, he said, “We want to, we’re try-ing to, but we’re not there yet.”]

To process this data, Hume uses noRAID, no SAN or NAS, no distrib-uted filesystems, and no specialhardware save for a high-speedlow-latency network and suitablehost adapters on each node. In-stead, data is broken into chunks,shipped to the next available nodein the cluster, and then processedlocally. In doing this sort of thing,Hume learned that networks anddisk controllers are not as reliableas previously thought. To handlethese unreported errors, all data ischecksummed before and aftereach transfer, sometimes more thanonce. Part of Hume’s work is tryingto be able to prove that files are“correct” to a standard high enoughto be accepted in court. In part thisis being driven by legislation suchas the Sarbanes-Oxley Act.

Hume claims that backup systemsare getting worse; they now have tobuy new backup hardware aboutevery three years. His project cur-rently uses AIT-2, which he findsunacceptably slow. By comparison,computers get faster and more reli-able every time he buys them.

48 ; L O G I N : V O L . 2 9 , N O . 5

In the Q&A session, as a commenton a question from an audiencemember (to Voruganti), Andrewclaimed to be from “the KenThompson school of thought onexpert systems: there’s table look-up, fraud, and grand fraud.”


Summarized by Richard S. Cox

Network Complexity: How Do IManage All of This?

Eliot Lear, Cisco Systems

Eliot presented an appeal for workon network management. Whileproviders were previously con-cerned with only a few very expen-sive devices, we now have a hugenumber and variety of devicesranging from routers and switchesto laptops and phones, all of whichneed to be monitored and managedin order to support critical networkapplications.

The first step in managing is toknow what is connected to the net-work. Unfortunately, today’s dis-covery mechanisms won’t work forthe millions of devices on futurenetworks. Instead, devices willneed to “call home” or send notifi-cation when their status changes.This presents issues from what toname the device to determiningwhere to send the notifications. Insome cases, there may be multipleinterested parties: for example, anISP, a VPN provider, a voice serviceprovider, as well as the customer,may all be interested in updatesfrom an IP phone; managing thiswhile respecting privacy and secu-rity is a major challenge.

Having found the network compo-nents, we next need to determinetheir current status. As a brightpoint, standards for monitoringand state retrieval from individualdevices, such as SNMPv3 and sys-log, are maturing and investment isbeing made in tools. Even simpledevices now support an SNMPinterface. However, dealing withthe large amounts of data generated

by all these devices is still anunsolved problem. Correlatingreports from multiple sources toidentify a fault or anomaly isimportant, both to limit theamount of information presentedto a human and to avoid burdeningthe infrastructure with excessivemanagement traffic. Some supportfrom the networking hardware—for example, programmable aggre-gation in the routers—might beuseful here.

Having determined the state of thenetwork, closing the loop requiresthe ability to control the devices.Here, standards are less advanced,though a certain amount of thatcan be attributed to the cutting-edge nature of the field. The NET-CONF protocol is an effort to pro-vide a common transport protocoland syntax for configuration, butvendor-independent configurationschemas are still unspecified.

G E N E R A L S E S S I O N PA P E R S :OV E R L AYS I N P R AC TI C E O OO

Summarized by Ningning Zhu

Handling Churn in a DHT

Sean Rhea, Dennis Geels, and JohnKubiatowicz, University of Califor-nia, Berkeley; Timothy Roscoe, IntelResearch

Awarded Best Paper

According to statistics from realP2P networks such as Kazaa, churn(“the continuous process of nodearrival and departure”) is prevalentin real life. Through experiment onModelNet—an emulated net-work—the authors show that sev-eral important distributed hashtable (DHT) variances (e.g., Tapes-try, Chord, and Pastry) all failed tohandle churn very efficiently.

This work identifies and exploresthree factors affecting DHT per-formance under churn: reactiveversus periodic failure recovery,message timeout calculation, andproximity neighbor selection.Results show that periodic recovery

is better than reactive recovery;TCP-style timeout calculations out-perform those based on a virtualcoordinate scheme; and simpleglobal sampling is as good as othermuch more sophisticated schemesin neighbor selection.

They’ve used the DHT implementa-tion Bamboo, which is derivedfrom Pastry but has been enhancedwith the above techniques to han-dle churn. The code and additionalinformation can be found athttp://bamboo-dht.org.

Q: Is TCP-style timeout doing wellbecause of absence of backgroundtraffic?

A: To some degree, the answer isprobably yes, although the bench-mark itself also creates some loadimbalance. In any case, backgroundtraffic would probably hurt per-formance of a virtual coordinatescheme as well.

Q: How did you have a good time-out for the return path, and howdid you measure latency when thereturn path was different from thelookup path?

A: There is an ACK for each lookupmessage on every hop to get laten-cies, and a conservative timeout isused for the return path. There isan average of five hops in thelookup and only one return hop, sothis conservative estimate isn’t toofar off. We could not have exploredthe possibilities of using virtualcoordinates for only the returnhop, or have the return path bealong the lookup path.

Q: In this paper, what is the dimen-sion of virtual coordinate space?

A: It is a 2.5 dimensions space withx and y in a plane and z above theplane. The distance between (x1,y1, z1) and (x2, y2, z2) is Z1 plusZ2 plus the square root of((x1–x2)2 + (y1–y2)2). The latestVivaldi work seems to indicate thatthis is a good metric.

Q: Why does Tapestry work fine insimulation but not so well in amore realistic network emulation?


A: Because Tapestry has no leaf set;Tapestry really needs to recoverquickly from routing table neigh-bor failures. This problem leads itto be built to recover reactively,therefore to suffer from the sameproblems that Bamboo/Pastryexhibits from reactive recovery.

Q: Have you tried some sort ofperiodic/reactive hybrid?

A: It is really hard to do withoutreverting to the policy of increasingtraffic under stress. There’s proba-bly some middle ground, but we’renot sure what it is yet.

A Network Positioning System forthe Internet

T.S. Eugene Ng, Rice University; HuiZhang, Carnegie Mellon University

Knowledge about network distanceis essential for the performanceoptimization of a large distributedsystem. For an n-node system,directly computing the delaybetween each pair of nodes takesO(n2) time. The author proposes tosolve the scalability issue by build-ing a network positioning system(NPS) using a Euclidean spacemodel. Each node infers its net-work coordinates by measuringtheir distance to several referencepoints, and network distancebetween any pair can then be calcu-lated by their network coordinates.

In building such a network posi-tioning system, there are manypractical issues, including systembootstrap, how to support a largenumber of hosts, how to select ref-erence points, how to maintainposition consistency, how to adaptto Internet dynamics, and how tomaintain position stability. The sys-tem is evaluated on PlanetLab with127 nodes using an 8D Euclideanmodel; results showed that positionaccuracy was fully maintainedthrough the 20-hour testing period.

Q: Is there any technique from NTPthat NPS can also benefit from,considering that NTP and NPShave some common issues to dealwith?

A: I’m not very familiar with NTPand therefore have no clear answer.

Q: Why did you choose to use 8DEuclidean space? Is there anythingparticularly important about thenumber of dimensions?

A: From my experience, 6 to 8dimensions would all be fine. Atoo-low number would not yieldthe desired accuracy, and a too-highnumber increases the calculationcomplexity.

Q: Has the system been tested on apractical Internet domain otherthan PlanetLab, which has a moreartificial environment? If yes, whatwas the result?

A: No. But I expect the scheme towork well on practical Internetdomains, too.

Q: Why did you choose Euclideanspace instead of another model?

A: Several other geometry modelswere explored; there wasn’t muchdifference in the result.

Early Experience with an InternetBroadcast System Based on Over-lay Multicast

Yang-hua Chu, Aditya Ganjam, San-jay G. Rao, Kunwadee Sripanidkul-chai, Jibin Zhan, and Hui Zhang,Carnegie Mellon University; T.S.Eugene Ng, Rice University

Internet multicast has been studiedfor many years; the protocol designand evaluation were mostly basedon static analysis and simulation.ESM (End System Multicast) is thefirst mature and deployed system touse Overlay Multicast for broad-casting video and audio streams.The system has had four publishersand 4000 users, providing uniqueexperiences on Internet broad-casting.

ESM requires no change to networkinfrastructure; the end hosts in anESM system are programmable tosupport application-specific cus-tomizations. ESM is a distributedand self-improving protocol opti-mized for end-to-end bandwidth. Itsupports heterogeneous receivers,

NATs, and firewalls, and has user-friendly managing tools. Theresults indicate that the overlay treebuilt by ESM is quite optimizedand well structured, and 90% of theusers get 90% of the bandwidth. Inthis paper, Kay Sripanidkulchaipresented a concept called“Resource Index” to quantify thebandwidth utilization in the sys-tem. When Resource Index indi-cates the system resource utiliza-tion is high, some users experiencedegradation of video quality. Oneimportant lesson learned from ESMis that there are a lot of NATs in thesystem (70%), which ties up re-sources and causes poor perfor-mance.

The ESM system can be accessedon line at http://esm.cs.cmu.edu.

Q: There have been several recentproposals, such as CoopNet andSplitStream, to use multiple treesfor streaming. From your experi-ence do you think multiple treeapproaches are necessary?

A: From what we’ve seen, singletrees seem to do fairly well, thoughfor larger-scale groups, multipletrees may become useful.

Q: How do you deal with the dataproxy server in your system?

A: It is counted as NAT behind fire-wall.

Q: How do you avoid “free rides,”i.e., when a user lies about theresource that he or she is going tocontribute to the system?

A: ESM uses actual measurementinstead of trusting a user’s claim.

50 ; L O G I N : V O L . 2 9 , N O . 5

G E N E R A L S E S S I O N PA P E R S :S E C U R E S E RV I C E O O O O O O O

Summarized by Wanghong Yuan

Reliability and Security in theCoDeeN Content Distribution Net-work

Limin Wang, KyoungSoo Park,Ruoming Pang, Vivek Pai, and LarryPeterson, Princeton University

KyoungSoo Park first introducedCoDeeN, an academic content-dis-tribution network on PlanetLab,and its security problems. The rootof these problems is that CoDeeNhas no end-to-end authentication.KyoungSoo then described theirapproach to security, whichincludes multi-level rate limitingand privilege separation. Theyachieve reliability by using activelocal and peer monitoring. In addi-tion, he discussed DNS problemssolved via mapping objects in thesame proxy and CoDNS. Finally, he summarized the lessons andfuture work, including robot de-tection, CoDeploy and CoDNS.More information is available athttp://codeen.cs.princeton.edu.

Q: What causes the DNS problems?

A: Local DNS server overload.

Q: What are other solutions foraccessing local content?

A: More efficient approaches, withmore information; currently theprivilege separation is simple.

Building Secure High-PerformanceWeb Services with OKWS

Max Krohn, MIT

The motivation story is Spark-Match version 1, which crashedwith 500,000 signups. Version 2solved some problems in the data-base, but there were too many con-nections. Version 3 in 2002 distrib-uted database but the developmentcycle was too long. Max summa-rized the desired Web service fea-tures: thin fast server, smart gzipsupport, small number of databaseconnections, memory reclamation,and an easy and safe way to run

C/C++ code, and mentioned thatthe major problem is dynamic con-tent. Currently, Apache/PHP doesnot work well, due to the poorisolation.

Max then described their system,called the OK Web server (OKWS).Its design is that of a multi-serviceWeb site, and its isolation strategyis the least-privilege principle. Maxalso gave an example of how tobuild a Web service with OKWSand illustrated how the isolationworks in OKWS in detail. OKWS is implemented in C++ with SFSlibraries, database translationlibraries, and Perl-like tools. Thekey point is one process and onethread for one service, without syn-chronization. SparkMatchv4 isbuilt using OKWS, which com-pared favorably to Apache, Haboob,and Flash. The source code is avail-able at http://www.okws.org.

Q: Is there an advantage for notmaintaining the database pool?

A: Yes, based on observation ofApache.

Q: Why not replace script? Whydevelop a new Web server?

A: Security problems in Apache.

Q: How do you support tworequests sharing the same service?

A: It’s possible to do this; the paperhas more detail on how.

REX: Secure, Extensible RemoteExecution

Michael Kaminsky, Eric Peterson, M.Frans Kaashoek, and Kevin Fu, MIT;Daniel B. Giffin, David Mazières,New York University

The motivation is that remote exe-cution is important but there arefeatures not widely available in cur-rent tools. The major problemaddressed in REX is locating thesimplest abstraction that can sup-port all of these features. Michaeldescribed how to establish a ses-sion, run a program, pass filedescriptors, use X Window systemforwarding, connect through NATand dynamic IP address, and for-

ward restricted credentials. Theevaluation tries to answer twoquestions: Is REX reliable and arethere any architecture benefits?More information is available athttp://www.fs.net.

Q: Are there problems in fileaccess?

A: Only in some access, such aswrite and read.

Q: What is the relationshipbetween TCP and channel?

A: There is one TCP and there aremultiple channels.

U S E B S D S I G

Summarized by Adam S.Moskovitz

The NetBSD Update System

Alistair Crooks, The NetBSD Project

Alistair Crooks described a systemfor downloading and installingbinary patches, similar in manyways to Microsoft’s WindowsUpdate Facility, but for use on anynumber of platforms. Crooks’ sys-tem runs on a variety of platforms,including the *BSD variants, MacOS X, Linux, and Solaris. Like theMicrosoft system, NetBSD Updateis easy to use and gives the userthree options for automatic behav-ior: inform the user; inform anddownload appropriate packages;inform, download, and install thepackages/patches. Crooks uses afile on the update server to listpackages for which vulnerabilitiesexist and a program that runs onthe target system to say which ofthose packages is present andshould be updated.

NetBSD Update includes otherimportant features, the most signif-icant (in my mind) being the abilityto digitally sign update packagesand the user’s ability to accept orreject those updates based on thevalidity of the signature(s). Unfor-tunately, like so many other sys-tems, the lack of a widely acceptedpublic key infrastructure meansthis feature is still a bit more cum-


bersome than it ought to be(which, of course, should not beconsidered a shortcoming ofCrooks’ work).

Another feature is the ability toundo the effects of an update.NetBSD Update automatically pre-serves all files that will be overwrit-ten and stores them for the user incase the update causes more prob-lems than it solves, or if worse vul-nerabilities are found in the updatethan existed in the unpatched sys-tem. [Summarizer’s note: Ofcourse, this sort of thing has neverhappened—the phrase “the patchfor the latest jumbo patch” ismerely a joke among systemadministrators.]

A Software Approach to Distribut-ing Requests for DNS ServiceUsing GNU Zebra, ISC BIND 9,and FreeBSD

Joe Abley, Internet Systems Consor-tium, Inc.

[Summarizer’s note: This talk/sys-tem deals with certain aspects ofrouting that go beyond my generalknowledge of the subject; if some-thing you read doesn’t make sense,the error is almost certainly mineand not the speaker’s.]

Joe Abley described a system fordistributing DNS requests acrossmultiple hosts without the use ofdedicated load balancers, by usinga “service address” (sometimescalled a “virtual IP address”), any-cast, and the Equal Cost Multi-Path(ECMP) feature of the OSPF rout-ing protocol. This system is cur-rently in use for the F root nameserver (run by ISC—the InternetSystems Consortium), which alsoprovides slave service for 30–40ccTLDs. Currently, 24 nodes acrossCalifornia and in New York, Tokyo,and Stockholm make up whatappears to be a single root nameserver.

Individual nodes in the cluster areconfigured with unique unicast IPaddresses, and with the serviceaddress on the loopback interface.Hosts inform the routers of their

readiness to answer requests viaOSPF Link State Advertisements;simple wrapper informs the routerwhen an instance of “named” fails(internal assertion failures are setto dump core and exit).

For UDP-based DNS queries, itdoesn’t matter which node in acluster provides the answer. ForTCP-based operations like zonetransfers, all packets in the transac-tion must be routed to a singlenode; Abley uses a combination of“flow hashing” (via Cisco ExpressForwarding or the “load-balanceper-packet” feature on Juniperrouters), avoiding ECMP routes forstateful transactions, and usingBGP.

G E N E R A L S E S S I O N PA P E R S : OTH E N E T WO R K- A P P L I C ATI O NI NTE R FAC E O O O O O O O O O O O

Summarized by CalicratesPolicroniades

Network Subsystems Reloaded: A High-Performance, DefensibleNetwork Subsystem

Anshumal Sinha, Sandeep Sarat, andJonathan S. Shapiro, Johns HopkinsUniversity

Anshumal Sinha introduced histalk with several issues observed inin-kernel monolithic network sys-tems: security (they represent a sin-gle point of failure), maintainability(robustness-critical code is largeand difficult to maintain anddebug), and flexibility (lack of sup-port for the simultaneous existenceof multiple protocols, complexityto do application-specific optimiza-tions). He stressed that monolithicnetwork systems are only usedbecause of their performance bene-fits. The author mentioned thatprevious user-level implementa-tions have failed to deliver suffi-cient throughput, noting, however,their hypothesis that earlier sys-tems failed to provide an appropri-ate solution to a key problem: per-formance degradation resultingfrom data copying from one

address space to another in order toprovide protection domain bound-aries efficiently. Failing to properlymanipulate data from different pro-tection domains degrades the per-formance of the system.

The author then presented themethodology to evaluate their solu-tion. Based on the EROS micro-ker-nel to support domain factoring,they built two network subsystemsto evaluate the costs due to theuser-level implementation, thedomain factoring, and the micro-kernel performance. In particular,they built an EROS-based mono-lithic network subsystem and anEROS-based domain factored net-work subsystem. Anshumalexplained in detail the implementa-tion of both systems and their dis-tinctive features. When presentingexperimental results and evalua-tion, he included a conventionalLinux in-kernel network stack as areference baseline for performancecomparison. A detailed explanationof their results in terms of latencyand throughput showed that theperformance exhibited by thedomain factored network subsys-tem was comparable or close to theother two strategies (EROS mono-lithic approach and conventionalLinux network stack).

Anshumal concluded his talk byremarking that domain factoring ismore feasible than previouslyassumed, that the instruction cacheplays a significant role in the per-formance of the system, and thatfactoring provides the basis fordefensible systems.

accept()able Strategies for Improv-ing Web Server Performance

Tim Brecht, David Pariag, and LouayGammo, University of Waterloo

Tim Brecht discussed how particu-lar strategies to handle connectionrequests affect the performance ofWeb servers. He began by mention-ing how to improve Web servers’performance by modifying theircorresponding accept strategies. Hementioned that an adequate solu-

52 ; L O G I N : V O L . 2 9 , N O . 5

tion should not only improve Webservers’ peak performance but alsobe able to maintain it even underoverload conditions with a largenumber of connections. He pre-sented throughput results for threearchitecturally different Webservers: the event-driven, user-mode micro-server (39–71%improvement); the multi-threaded,user-mode Knot (0–32%); and thekernel-mode TUX (19–36%).

Tim stressed that current multi-accept servers overemphasizeacceptance of new connections andignore the processing of existingconnections. Second, he mentionedthat his work aimed to reduce thegap in performance typically seenbetween kernel-mode and user-mode servers. Next, he described indetail the three architectures thatwere analyzed in the paper andexplained how the accept-limit,which defines an upper limit on thenumber of connections acceptedconsecutively, affects each tech-nique’s performance.

The presenter made a careful analy-sis of the impact of varying theaccept-limit on each of the serversbased on their experimental results.In his experiments they used twoworkloads: a one-packet workloadand a SpecWeb99-like workloadthat uses httperf to generate over-load conditions. The experimentalresults presented by the authorwere organized by server perform-ance, queue drop rates, and laten-cies observed under differentaccept-limit policies. Tim men-tioned that it is necessary to ensurethat Web servers accept connec-tions at sufficiently high rates sothat a balance between acceptingand working times can be ade-quately established. Finally, he saidthey were able to demonstrate thatperformance improvements can beobtained by modifying the acceptstrategies used in Web servers.

Lazy Asynchronous I/O for Event-Driven Servers

Khaled Elmeleegy, Anupam Chanda,and Alan L. Cox, Rice University;Willy Zwaenepoel, EPFL, LausannePresenter: Khaled Elmeleegy

Khaled Elmeleegy began his pres-entation explaining why event-driven architectures are used andthe difficulties that programmersexperience when developing high-performance servers using existingI/O libraries. He remarked that cur-rent I/O libraries have an incom-plete coverage or leave to applica-tions the burden of state main-tenance. In contrast, Lazy Asyn-chronous I/O (LAIO) is a goodoption to develop high-perform-ance, event-driven servers with lessprogramming effort, because it cov-ers all possible blocking I/O calls,creates a continuation only whenan operation actually blocks, andnotifies applications only when ablocking operation has been whollycompleted. Next, Khaled explainedthe way in which event-drivenservers generally work and the rolethat event-handlers play in theiroperation; he also mentioned howblocking operations degrade serverthroughput. He presented LAIO asa solution to the typical blockingproblems seen in event-drivenservers and proceeded to describethe LAIO API, their functions, andimplementation.

After introducing the two differentworkloads used in their experi-ments, Khaled compared LAIO’sthroughput and performanceagainst other I/O libraries. Withthis purpose, the authors modifiedthe networking and disk I/O strate-gies of the Flash Web server andmeasured the results obtained fordifferent versions of the server. Insituations where performance wascomparable, the complexity of theprograms decreased because it isnot necessary to write handlers orto maintain state as in conventionalnon-blocking I/O, which finallyleads to a reduction of the amountof code that needs to be written.

Khaled finished his talk by high-lighting LAIO’s generality (coveringall the I/O calls) and simplicity(requiring fewer lines of code with-out handlers or the need to main-tain state). In terms of throughput,LAIO meets or exceeds the per-formance of other methods. DuringQ&A, the audience mainly focusedon comparing LAIO with multi-threaded servers; Khaled men-tioned, however, they had decidedto focus the study on event-drivenstrategies.

U S E B S D S I G

Summarized by Matus Telgarsky

Building a Secure Digital CinemaServer Using FreeBSD

Nate Lawson, CryptographyResearch

Nate’s dense, practical, and oftenanecdotal talk went beyond generalcrypto issues and concepts to alsodiscuss the troubles and travailsafflicting construction of a digitalcinema server and problems withits wide acceptance.

After providing a quick overview ofCryptography Research Inc., Natepresented an extremely cogent dia-gram that proved one of the strong-est bromides of the security cir-cuit—you are only as strong asyour weakest link. A graph pittedprobability of compromise againsteffort/cost of attack. The perfectscenario features a deep curve pre-dicting massive effort for even theslightest crack; however, usual cir-cumstances produce an almostinverted curve (symmetric againsty=x), where bribing employees,using common scripted attacks,and abusing operating system holesis often easy and constitutes themajority of compromises, ratherthan a crack of an encryption key, ashield many often deem fullysufficient.

Nate continued to describe threefundamental underpinnings of any security paradigm: strength(which encryption provides),


assurance (pragmatic assessment ofattack methods, especially easierentrances), and renewability (post-mortem reconstruction).

Traditional analogue cinema (obvi-ously) uses film cameras, is trans-ferred to a digital format for post-processing (effects, editing, etc.), is printed thousands of times (at$3,000 a copy, which degrades aftera week of use anyway), and isplayed on $30,000 projectors. Digi-tal cinema is directly captured tohard drives and obviously omitsany tedious conversion; however,distribution and projection stan-dards do not exist—costs are pro-hibitive, and the market is in flux.Not only does refitting cost around$100,000, but there are even ques-tions whether the theater is respon-sible for said expenditure. In 2003,only 90 theaters in the U.S. weredigital (30 in 2000).

Digi-Flicks enlisted CryptographyResearch to design a new securitysystem and, hopefully, extend digi-tal cinema acceptance. Planneddesign goals were transport inde-pendence, thorough use of strongcrypto algorithms, multi-factorauthentication (i.e., simultaneouslyutilized smart card, pass code, andkey file), flexible authorizationpolicies, reliable playback overimperfect media, and, of course, arapid development cycle. Amus-ingly enough, for the 300 targettheaters, shipping hard drives wasfound to be the most cost-effectivedistribution method.

The sample extant hardware wasrather unpleasant—a simple UNIX-like OS over a 33MHz PowerPCwith 64MB RAM, too many ASICs,and no documentation. Serial andeven Ethernet proved too slow fordata transmission, so the SCSIinterface was selected to actuallytransfer the films (FreeBSD wasselected partially due to the easewith which the disc access codecould be modified to play nice withthis chaotic configuration). Theencrypted drive would be decodedwith a smart card and by dialing in

to an auth server. Nate spent amoment covering common pitfallsin encryption selection, includingan amusing pair of images present-ing a still identifiable pattern in anencrypted image due to naivelysmall block selection.

A recurring suggestion was carefulthread-model analysis in order torealistically and sensibly determinecircumstances and identify weakpoints, and then assign designparameters accordingly. Natedetailed many possible scenarios(one-time read-only access,repeated read-only access, one-timeread-write access, and repeatedread-write access) and the specificdangers within each. Similarly, agood security structure depends onclear top-down study and carefulperusal of all possibilities.

Panel: The State of the BSD Pro-jects

Chair: Marshall Kirk McKusick

The FreeBSD Project: Robert Wat-son, Core Team Member, TheFreeBSD Project

The NetBSD Project: ChristosZoulas, President, NetBSD Founda-tion

The DragonFly BSD Project: MattDillon, Project Leader, The Dragon-Fly BSD Project

All attending BSD parties were ableto give impromptu presentationsdetailing past work, current revela-tions, and future plans. FreeBSD,NetBSD, and DragonFly BSD wererepresented; rumblings aboundedregarding Darwin and OpenBSD,supporters of which were unfortu-nately concurrently occupied withother tasks.

Robert Watson’s speedy flightthrough FreeBSD 4 (stable) and 5(development) built a good meas-ure of excitement and confidencein the impressive list of featuresstabilizing in the new code. 4.10has survived healthily with minorsecurity updates and has enjoyedhardened security. 5.X has been incontinuous development for five

years, with hard work solidifying anew SMP model and threadingcore, among numerous otherimprovements. 5.3 features includegcc 3.4, PCI and ACPI work, X.orgX server, more fine-grained lockingwork (including heavy “giant” lockremoval in many subsystems), SMPthread scheduler tweaks, and theflexible pf packet filter, among oth-ers. SMPng is satisfactorily transi-tioning from bug and correctnesschecking to performance tuning.

Next came Alistair Crooks present-ing NetBSD, alive since 1993 andeagerly awaiting a 2.0 release.Nascent features include SMPwork, scheduler activations,kqueues, wireless drivers, andmany other features. A primarygoal of NetBSD is to function onmany architectures—thenetbsd.org sidebar presents animpressive list of 54 disparatedevices. Time was also spentdescribing the package distributionsystem, pkgsrc, which is easily con-figurable, consistent, supports mul-tiple versions of installed programs,and currently boasts over 4500packages.

Matt Dillon discussed his ambi-tious DragonFly BSD project,which is steadily advancing upon a1.0 release. Already a veteranhacker (contributor to Linux andFreeBSD, among many other proj-ects), Matt’s aggressively progres-sive plan for restructuring BSDrevolves around a message-passingcore with a lightweight IPC model.Much of the talk and current focusis extremely low level—forinstance, much focus is going intorestructuring to optimize cacheusage in all subsystems, from theground up. One corollary goal isminimizing use of fine-grainedmutexes. DragonFly is a continua-tion of FreeBSD 4.X, though apleasant rapport exists with theparent project, and indeed updatesstill filter through.

This enthusiastic one and a halfhour panel showed the BSD proj-ects to be in excellent condition,

54 ; L O G I N : V O L . 2 9 , N O . 5

with a dedicated group of hackersbacking each—in fact, one of thefew times I witnessed the BSDhackers leaving the laptop room(and their diligent hackery) was toattend this informative panel.FreeBSD and NetBSD pointed outtheir foundations, facilitating dona-tions through cheerily tax-deductible exchanges. DragonFlyhas not yet formed a foundation,though Matt Dillon would certainlyenjoy frequent surreptitious anony-mous gifts.


Summarized by Swaroop Sridhar

Thinking Sensibly About Securityin an Uncertain World

Bruce Schneier, Counterpane InternetSecurity, Inc.

Mr. Bruce Schneier delivered histhought-provoking and entertain-ing talk without any kind of visualaid. He began by saying that we areliving in an interesting era called“silly security season.” Introducingthe notion of all of us being “secu-rity consumers,” he said that weneed to step back and analyzewhether this security is reallyworth it. Is it worth the billions ofdollars and the loss of convenience,anonymity, performance, or free-dom? Elaborating on securitytrade-offs, he said that it is wellknown that trade-offs are ubiqui-tous, but there is a fundamentalsecurity trade-off paradox: We,who claim to be the “most intelli-gent” species on the face of thisearth, always make the wrong secu-rity trade-offs. Much of Schneier’stalk was based on why this is soand how it could be fixed.

Schneier said that the way to dogood security trade-offs is to slowdown and have a basis for rationaldiscussion, rather than makingquick decisions based on emotions.However, he warned that this couldbe quite complicated because themeaning of factors such as incon-

venience, risk, and privacy areoften subjective.

Next, Schneier brought up thetopic of risk assessment. He warnedthat people are always botheredabout “spectacular” risks (e.g.,risks while flying in a plane) anddownplay “pedestrian” or “undercontrol” risks (e.g., risks whiledriving), which matter much morein our lives. Schneier identifiedtechnology and media as two mainculprits causing this problem.News, by definition, means thatwhich does not happen every day.The media only show the uncom-mon happenings, replaying themover and over to create a feelingthat they are very common. Tech-nology contributes its bit, obscur-ing risks by hiding operationaldetails from users.

Again, bringing up the topic of whyextreme trade-offs (such asNational ID cards) are taken for lit-tle gain, Schneier said that securitydecisions are usually made for non-security reasons. This leads to anotion of an “agenda” among allthe “players” of the bigger system,of which security is a part. Forexample, closing national highwaysis good according to a policeagenda, but bad according to a pub-lic agenda. Schneier proposed amodel of “Security Utilitarian-ism”—which leads to the greatestsecurity for the greatest number ofpeople.

Schneier stated that one of the fun-damental problems is that we oftenhave no control over the securitypolicies that are implemented. Theright kind of security should beworked out by means of negotia-tions and deliberations. He cau-tioned, however, that the negotia-tions should be held at the righttime, with the right people. Argu-ing with a security guard at an air-port gate, for example, would be abad idea. Schneier identified fourfactors that can effect a change insecurity norms—government rulesand laws, market forces (e.g., refus-ing to use an insecure OS), technol-

ogy, and social norms. He said thatby turning the above four knobs,we must be able to work out theright kind of security.

Later, Schneier said that we need toaccept the risks as real, and try toreduce them. He also proposed thatone possible solution is to put theperson who can best mitigate therisk in charge of the risk. He illus-trated this point with the exampleof a supermarket cash register,where the customer is “used” toguard against cashier malpractices.Schneier concluded by saying thatas individuals we have very littlepower, but as an aggregate we canachieve a lot toward our collectivegood.

G E N E R A L S E S S I O N PA P E R S :U N P LU G G E D O O O O O O O O O

Summarized by Matus Telgarsky

Energy Efficient Prefetching andCaching

Athanasios E. Papathanasiou andMichael L. Scott, University ofRochester

Awarded Best Paper

Modern operating system designprescribes a plethora of heuristicsfor caching and prefetching to aidin disk performance, with nary aword about energy savings. Studiesattribute 9–32% of laptop energyexpenditure to hard disk use;hence, heavy savings in that realmwill result in drastic overallimprovements.

Traditional prefetching techniquesaim to reduce disk access latencyby attempting to maintain theworking set of an application’s diskdata cached by replacing unusedcache elements with simplisticallydetermined prefetch targets. Unfor-tunately, this does not preclude thepossibility of an application readingand writing at arbitrary times, obvi-ating the possibility of simply tack-ing on any sort of basic power man-agement scheme. Indeed, many ofthe tests on a stock Linux kernel


showed 100% of the disk idle timesto fall beneath one second, notnearly long enough to enter a disk’spower-saving state without incur-ring a net power efficiency lossowing to energy required fortransition.

The presentation detailed thedesign and implementation ofBursty, a mechanism providinghighly speculative prefetching, akernel interface to hint disk accesspatterns, and a daemon both tomonitor and manage the system.Applications may hint improperly,or lack hints entirely, so the moni-tor must both generate and judgeextant hints. The prefetching is alsoself-aware—the success rate of thealgorithm is constantly measuredto determine whether furtheradjustments are required. Addition-ally, per-application idle times areirrelevant if they are not in phasebetween applications; hence, thedaemon also attempts to organizethese patterns to allow for consis-tent disk avoidance between allapplications. Once the predictedidle period is estimated to beyondthe intersection of regular drive useand idle use combined with transi-tion expenditure, the drive is pow-ered down into an appropriate low-power mode. A variety of tests withdifferent applications using a vari-ety of workloads and disk accesspatterns (and memory configura-tions—Bursty is hungry!) found60–80% energy savings, with negli-gible losses in efficiency.

Time-Based Fairness ImprovesPerformance in Multi-RateWLANs

Godfrey Tan and John Guttag, MIT

Modern Wireless networks theoret-ically maintain decent throughputwhen congested, though in practicethe common utilization of ratediversity as an automatic signalstrengthening scheme causes stan-dard throughput-based fairnessschemes to result in unexpectedlypoor performance. This paper pre-sents an overview of the problem,

design and implementation of asolution—termed “time-basedfairness”—and experimentalverification.

802.11b was used as the test case.Though traditionally known tosport 11Mbps, the standard alsodefines three other rates: 1, 2, and5.5. Vendors use these speeds whenpacket transmission failure becomesa problem, eventually bumping thespeed to the slowest rate, whichfeatures the highest signal resil-ience. Current channel proportion-ing and access point downlinkscheduling techniques result inthroughput-based fairness, mean-ing a slower rate receives a largerportion of channel time, ostensiblyaiding the feeble companion butcausing the hare to be tied to theturtle.

Time-based fairness apportionschannel use equally by time, result-ing in much higher possiblethroughput. The average time fornetwork tasks to complete is alsoreduced, obviously a benefit tomany mobile users and definitely to anyone who would rather havethings to do while a laggy transmis-sion completes. The implementa-tion is flexible enough to functionproperly on extant access pointsand does not need extensive modi-fication on clients; adoption is easyand backwards-compatible.

EmStar: A Software Environmentfor Developing and DeployingWireless Sensor Networks

Lewis Girod, Jeremy Elson, AlbertoCerpa, Thanos Stathopoulos, NithyaRamanathan, and Deborah Estrin,UCLA

The burgeoning study, experimen-tation, and deployment of wirelesssensor network applications is gen-erating a need for full-fledgeddevelopment suites. EmStar pro-vides just that for 32-bit embeddedMicroServer platforms: tools andlibraries providing simulation,visualization, and emulation. Otherfunctionality aids in development

and testing of IPC and networkcommunication.

Due to time constraints, a largeportion of the talk focused onFUSD (Framework for User-SpaceDevices), which is a kernel moduleproxy to device file events. FUSD,though new, is already used bynumerous applications to simplifycommunication with device nodes.It is essentially a micro-kernelextension to Linux. At the mo-ment, performance is sufficient butunsatisfactory; read throughput, forinstance, can be 3 to 17 times slow-er than analogous read perform-ance without the FUSD proxy over-head.

EmSim and EmCee are simulationtools; these in turn are modular toallow for easy extension and mini-mized footprint. EmRun starts up,maintains, and shuts down anEmStar system according to a pol-icy in a configuration file; it fea-tures process respawn, in-memorylogging, fast startup, and gracefulshutdown. All components (morethan are listed here) are writtenwith modularity in mind, and codeis heavily reused. It has alreadyproved useful in numerous projectsat the CENS labs working with avariegated set of hardware.

S E C U R IT Y S I G

Summarized by Ming Chow

Panel: The Politicization ofSecurity

Moderator: Avi Rubin, Johns HopkinsUniversity

Panelists: Ed Felten, Princeton Uni-versity; Jeff Grove, ACM; GaryMcGraw, Cigital

The common theme of this panelwas how politicized security, espe-cially that relating to technology,has become. Professor Avi Rubinspoke of his experiences workingon the issue of electronic voting(eVoting). He spoke about dealingwith policy issues, and about howeVoting has become a partisan,politically charged issue and, as

56 ; L O G I N : V O L . 2 9 , N O . 5

such, is targeted for abuse. Anexample is that companies produc-ing eVoting technologies andequipment have strong politicalties. The goal from each politicalparty is to “not have the other guywin.” Professor Rubin has been onmajor news sources (e.g., CNN)speaking about technical issues ofeVoting, and has received numer-ous telephone calls from bothDemocrats and Republicans. Pro-fessor Rubin recounted being calledto testify in front of Congress abouteVoting, and recalled the amount offighting and bickering on bothpolitical sides dealing with theissue. He summed up the currentstate of politics by saying that “par-tisanship has never been worse.”

Gary McGraw spoke of the longhistory of politicization of scientificresearch and development and thedegree to which current scientificresearch and development areinfluenced by politics (like Galileoand Darwin centuries ago). Hestated that security and terrorismare sensitive subjects, and that “weshould understand the problem,having worked in an asymmetricsituation for years in computersecurity.” McGraw also said thattoo often “individual rights can betrumped in the name of security”(e.g., DMCA and the Patriot Act).

Jeff Grove has worked with thegovernment on Capitol Hill, andexpressed his dissatisfaction on thenumber of bad laws being imple-mented, including the DMCA, andthe regulation of P2P networks.Grove outlined how the Senate canaddress and jump on issues andmake dumb laws. The problem per-sists because of bad conclusions,bad assumptions, and lack of basicunderstanding about technologies.In addition, there is a small handfulof powerful players who are effec-tive in influencing the governmentto create laws fitting their agendas.Bad laws expose developers to lia-bilities, even when there’s noinfringement, and provide civilenforcement by encouraging legal

actions by the entertainmentindustry.

Professor Ed Felten spoke aboutthe Digital Millennium CopyrightAct (DMCA) and his work, whichmade national headlines severalyears ago. Professor Felten statedthat the DMCA was created bynegotiations in which computerscientists were not involved. Hiswork with advisee John Haldermanwas discussed—the weak DRMtechnology created by SunnCommcould be bypassed on Windowscomputers by holding down theshift key. The government wascracking down on Professor Fel-ten’s research and he was threat-ened by the RIAA under theDMCA. Professor Felten settledwith both Princeton University andthe government by creating educa-tional packets for the governmenton security research. Professor Fel-ten recalled testifying in Congressabout a bill to limit developingtools on decoding technologies,and summarized the atmosphere in one word: “theater.” Finally, hegave out his Web site:http://www.freedom-to-tinker.com.

The theme from all of the panelspeakers was clear: “We (the com-puting and scientific communities)need to step up to the plate andeducate people on technologicalissues.” The goal can be accom-plished by being more involved, bybeing partisan, and by talking toanyone who is curious. Opennessand debate are encouraged and arehealthy. It is critical to tell the truthand to convince people aboutwhat’s really going on. GaryMcGraw also said that attackingsystems is a necessary part of secu-rity and that outlawing attacksmakes little sense. Finally, mediaand politics are great investments:the “Slashdot effect” helps ridiculebad laws, and working even withyour local government is a 10–15-year investment.

F R E E N I X O P E N I N G R E M A R KS A N D AWA R D S O O O O O O O O O O

Summarized by MartinMichlmayr

Bart Massey, Portland State Univer-sity; Keith Packard, Hewlett-PackardCambridge Research Lab

Bart Massey and Keith Packardopened the FREENIX track, aforum devoted to free and opensource software, by giving a briefsummary of papers that were sub-mitted this year. Out of 61 paperssubmitted, 15 were accepted. Theorganizers were happy to see thatamong the accepted papers, sevenwere from students, and seven werenon-US papers. They said that thequality of all submitted papers wasvery high and that the reviewprocess was more formal than inthe last few years, adding threeexternal reviewers to the programcommittee. They also thankedDoCoMo for sponsoring studenttravel for the conference.

In this opening speech, two awardsto papers in the FREENIX trackwere given. The Best Paper awardwent to “Wayback: A User-levelVersioning File System for Linux,”and the Best Student Paper was“Design and Implementation ofNetdude, a Framework for PacketTrace Manipulation.”

There will be another FREENIXtrack at USENIX ’05 in Anaheim,California. Since future USENIXconferences will take place aroundApril, the deadline for FREENIXsubmissions is October 22, 2004,rather than in December. Moreinformation on the next FREENIXtrack and Call for Papers can befound at http://www.usenix.org/events/usenix05/cfp/freenix.html.


F R E E N I X I N V ITE D TA L K

Summarized by MartinMichlmayr

The Technical Changes in Qt Version 4O

Matthias Ettrich, TrolltechLinux/Open Source

Matthias Ettrich, founder of theKDE project and a main developeron Qt, gave an overview of the nextgeneration of Qt, a cross-platformC++ GUI toolkit. Qt supports X11,Microsoft Windows, Mac OS X, andembedded Linux, and offers nativelook and feel on each of these plat-forms. Qt provides single-sourcecompatibility: one source codecompiles on all target platforms.While Qt mainly offered GUI func-tions in the past, it is much morethan a GUI library these days: Italso supports I/O, printing, net-working, SQL, process handling,and threading. One aim of Qt is toprovide an excellent programmingexperience.

Qt introduced the signals-and-slotconcept in order to allow differentGUI components to communicate.You can connect any signal to anynumber of slots in any module, andcommunication is done at runtime.

USENIX ANNUAL conference TECHNICAL reports · 2019. 2. 25. · Novell was able to do ver y well...

Documents

Transcript of USENIX ANNUAL conference TECHNICAL reports · 2019. 2. 25. · Novell was able to do ver y well...