OSDI2010摘要中文翻译

OSDI2010摘要中文翻译一、Comet:Anactivedistributedkey-valuestore［Comet：一种主动分布式的键-值存储］分布式键-值存储系统被广泛的应用在企业和互联网上。我们的研究通过特定应用制定来寻找大幅度提高键-值存储系统应用空间的方法。我们设计实现了一个网络（Comet）——一个可扩展的键-值分布式存储系统。每个网络节点存储了一组主动存储对象（ASOs），这些对象包含了一个键，一个值以及一系列的处理程序。Comet处理程序运行返回定时器或者存储操作的结果，比如get和put，这样它就允许一个主动存储对象执行动态的，针对特定应用的动作来自定义自己的行为。处理程序都是用简单的具有沙箱扩展型的语言编写，以此提供安全和独立的特性。我们为Vuze（开发小组，开发了JavaTorrent客户端，支持I2P和Tor匿名网络协议）DHT（DistributedHashTable分布式哈希表）实现了一个Comet原型，在PlanetLab（新一代互联网，计算服务“覆盖网络”）将网络节点部署在Vuze上，并创建了许多的Comet应用。实验结果证明简单性，安全性和受限制的扩展性可以大幅度提高分布式主动存储系统应用的能力。这项研究通过各种需求的应用证明了该研究有利于单一存储系统的共享，并且能加强如今巨型云的内部效率。二、Depot:Cloudstoragewithminimaltrust［Depot：基于最小信任的云存储］该论文介绍了一种基于最小信任假设的云存储系统的设计、实现和评估。Depot系统即使在经受了大量的客户端和服务器的漏洞和恶意的测试下，也能为正确的客户提供安全性和现场的保证。这种保证来自Depot使用了两层架构。首先，Depot保证由正确节点发现的更新能固定的遵守FJC（Fork-Join-Causal）一致性。FJC是在有错误节点的情况下也能保持安全性和现场性的因果一致性的一种轻度削弱。其次，Depot实现了一种使用这些一致更新规则提供合适的一致性、疲劳性、持久性和恢复性的协议。我们的评估证明了提供这些保证的代价是可以接受的，并且即使在重大错误发生时，Depot可以承受错误，保持良好的可用性，等待性，间接性，和疲劳性。［注*因果一致性：假设进程P1写变量x，然后P2读出乂，写入）。这里读出x和写入y之间可能有潜在的因果联系，因为y的计算很可能决定于P2读到的x值（即P1写入的值）］三、SPORC:GroupCollaborationusingUntrustedCloudResources［SPORC:使用不可信任云资源的组协作］对于面向用户的应用，比如文字处理软件和日历软件，云服务是一种很具有吸引力的部署模型。不同于桌面应用，云服务允许多个用户同时和实时的编辑共享的状态，从而使得它变得可扩展性，高可用性和全局访问性。不幸的是，这些利处是基于信赖云提供商通过提供潜在敏感和重要的数据的代价实现的。为了克服这种严格的权衡，我们提出了SPORC，一种使用不可信任的服务器来构建各种协作应用的通用框架。在SPORC里，服务器只能看到加密后的数据而且一旦偏离正确的执行就会被发现。SPORC支持同时的低延迟的编辑共享状态，允许离线操作，支持并发状态下的动态访问控制。我们使用两个原型应用来证明SPORC的灵活性：一个是因果一致性的键值存储系统和一个基于浏览器协作的文本编辑器。概念上，SPORC说明了操作转换（OT，operationtransformation）和分支一致ftCforkconsistency）的互补利益。前者允许SPORC客户端在不带互斥琐的前提下执行同时操作来自动解决结果冲突。后者可以阻止不正常行为的服务器执行模棱两可的操作顺序，除非它想把用户分为不相交的集合。值得注意的是，不想以前的系统，SPORC可以自动从通过利用操作转换（OT）的冲突解决机制进行恶意的分支操作中恢复。四、AdHocSynchronizationConsideredHarmful［点对点模式被认为是有害的］许多在现有的多线程程序中的同步操作是通过点对点模式［AdHot］来实现的。本文的第一部分针对并行程序的同步的特性做了全面的研究。通过对12个各种各样程序（服务器程序，桌面程序，科学计算程序）的299Adhot同步操作的研究，包括Apache，MySQL，Mozilla等等，我们发现一些有趣的有可能带有警告意味的特点：（1）每个研究的应用都使用了AdHoc操作。尤其是，每个程序中有6-83不等的AdHoc同步操作。（2）AdHoc的同步操作是容易出错的。显著比例（22-67%）的AdHoc同步操作产生了bug和严重的性能问题。（3）AdHoc的同步操作的实现是多种多样的，而且之间许多同步不能被简单的认为是同步，缺乏可读性和可维护性。我们的第二部分工作创建了一个名字叫同步发现器（SyncFinder）的工具去自动识别和注解用C/C++书写的并发程序的AdHoc同步操作来帮助程序员把他们的代码移植到更好的结构实现中，然而同时也能允许其他工具能识别出程序中的同步操作。通过对25个并发程序的评估显示，平均来看，SyncFinder能自动识别出96%的AdHoc同步操作，误报率是6%。我们也构造了两个用例来利用SyncFinder的自动注解功能。第一个例子使用注解工具检测到5个死锁（包括两个新的死锁）和16个潜在的问题，而这些问题是以往的工具比如Apache，MySQL，Mozilla发现不了的。第二个例子将Valgrind的数据竞争检查的误报率降低了43-86%。［*注：Valgrind：一款用于内存调试、内存泄漏检测以及性能分析的软件开发工具］五、BypassingRacesinLiveApplicationswithExecutionFilters［使用执行过滤器绕过现场应用的冲突］部署多线程的应用包含许多冲突，因为这些应用很难书写，测试和调试。糟糕的是，在部署程序中冲突数量可能会大幅度增加，原因在于多核的硬件和目前冲突探测器的不成熟。LOOM是一种“现场解决”的系统，它被设计成在执行时快速安全的绕过应用程序的冲突。LOOM为开发者提供了一个灵活的和安全的语言来书写执行过滤器（ExecutionFilters）来明确地同步代码。它使用一种评估算法安全的安装该过滤器到现场应用中来避免冲突。它通过混合检测（把静态的和动态的检测相结合）来降低性能的开销。我们从六个应用组成的多样集合中使用9个真正的冲突来对LOOM进行评估，包括MySQL和Apache。实验结果显示：（1）LOOM能及时的安全修复所有已经评估过的冲突，从而增强了应用的可用性；（2）LOOM需要很小的性能开销；（3）LOOM能随着应用线程数量的增加有很好的扩展性；（4）LOOM使用方便。六、EffectiveData-RaceDetectionfortheKernel［针对内核的有效数据冲突检测］数据冲突是当两个线程在没有合适的同步下错误的访问同一块共享的存储位置时产生的一类重要的并发错误。本文展示了DataCollider（数据对撞,DC），使用轻量级的有效的技术来探测内核模块的数据冲突。不像已有的数据冲突探测技术，DC忽略程序使用同步协议（比如琐原则）来保护共享内存的访问。这一点对于使用了无数复杂的针对特定架构和设备的同步机制的底层内核代码尤为重要。为了降低运行时开销，DC随机的抽取了一小部分内存访问作为数据冲突的代表。DC的关键新颖之处是它使用已经被许多硬件体系结构支持的断点机制来实现很小的运行时开销。我们已经为Win7的内核实现的DC，并发现了25个已经确认的数据访问冲突，而其中的12个已经被修复了。七、DeterministicProcessGroupsindOS［磁盘操作系统的确定性程序组］目前多处理器系统以不确定的方式执行并行和并发的软件程序：即使精确地给定相同的输入，相同的程序的两次执行也可能产生不同的结果。这使得调试，测试和自动容错复制更加的复杂。过去把解决问题的努力主要集中在记录和重现上，但是将执行过程确定化可以从根本上解决这个问题。我们工作的目标有两个方面：（1）把任意的，不可修改的多线程的程序充分确定的执行作为操作系统的服务。（2）将所有故意不确定的来源，比如网络IO接口转换为明确的和可控的。为此，我们提出了一个新的操作系统抽象，DPG（DeterministicProcessGroup）。所有内部的进程和线程之间的通信对于DPG来说发生是确定的，包括通过共享内存访问、操作系统通道（比如管道，信号量，文件系统）的通信。为了解决外部事件的根本不确定性，我们抽象出一个垫片层（shimlayer），一个嵌入在所有在DPG和外部世界交互之间的可编程的接口，使得确定性对反应性的应用尤为有用。我们把DPG抽象实现为Linux的扩展并使用三个用例证明它的有效性：纯精确的执行；可复制的执行；通过对外部输入做日志实现记录和重现。我们在并行和反应性的例子中评估了系统的实现，包括Apache，Chromium和PARSEC。八、EfficientSystem-EnforcedDeterministicParallelism［有效的强制系统确定性并行］确定性执行为调试，容错和安全性提供了很多的方便。然而，目前针对并行程序确定性执行的方法通常需要很高的开销，会使得不正当行为的软件击败可重复性，还使得依赖于时间的冲突转化成依赖于输入和路径的冲突，而不是去消除这些冲突。我们提出了一个并行程序模型来解决这些问题，并使用Determinator，一个概念证明型的操作系统，来证明模型的实用性。Determinator的微内核API仅仅提供“无共享”（shared-nothing）的地址空间和确定性的进程间通信原语来保证非特权代码一一不管是正常行为的还是不正常行为的代码一一都能重复精确的执行。在微内核之上，Determinator的用户层运行时适应乐观的重现技术为了向线程和进程级的并行程序提供私有工作区模型。这种模型避免了读/写数据冲突的产生，而且把写/写冲突转化为可靠检测的冲突。粗粒的并行基准在执行和扩展在多核PC和集群系统的交叉节点上对于非确定的系统是对等的。九、StableDeterministicMultithreadingthroughScheduleMemoization［利用调度记忆的可靠确定多线程技术］确定的多线程系统（DMT）消除了线程调度中的不确定性，简化了多线程程序的开发。然而，已有的DMT系统都是不稳定的；即使因为细微的输入和执行环境的差别，它们也会强制程序冒险进入大不相同的调度程序中，这样就破坏了确定性的优势。更甚，现有的DMT系统几乎不和输入连续不确定到达的服务程序一起工作。TERN是一个稳定的DMT系统。TERN最大的亮点是调度记忆的创意，就是存储过去工作调度的信息并把它们重复利用在将来的输入上，使得程序在不同输入下的行为保持稳定。TERN的第二个亮点是窗口化（windowing）的创意，就是针对服务程序扩展了调度记忆算法，通过将连续的请求流分割成一系列的请求窗口。我们的TERN在Linux上实现运行。它作为用户空间的调度器运行，不会对操作系统做任何改变并且仅仅对应用程序做若干行变化。我们使用真实综合的工作负载在14种不同的程序上对TERN进行测试。结果证明TERN简单易用，让程序更加确定和稳定，并且有合理的开销。十、AvailabilityinGloballyDistributedStorageSystems［全局分布式存储系统的可用性］高可用性的云存储系统通常是用复杂的构建在商业服务器和磁盘驱动集群顶端的多层分布式系统实现的。因此需要复杂的管理、负载均衡、恢复技术来实现在各种各样的错误源（包括软件、硬件、网络连接以及电源问题）之间的高性能和可用性。这样一来就有了一个相对充足的关于存储系统各个组成部分的错误研究，比如磁盘驱动器，但是目前关于大型云存储服务的报告还相对较少。我们通过对Google的主存储设施一年的广泛研究的基础上描述了云存储系统的可用性特性，并且提供了统计模型使得我们能更深入的洞察多种设计选择的影响，比如数据存放和复制策略。利用这些模型，结合我们在工作中发现的真实的失败模式，我们比较不同系统参数下的数据的可用性。十一、FindinganeedleinHaystack:Facebook’sphoto［大海捞针：Facebook的照片存储］本文描述了Haystack，一个针对Facebook相册应用的对象存储系统。Facebook目前存储了超过2600亿张图像，可以转化为超过20PB（1015字节）的数据。用户每周上传10亿张照片（大约60TB），Facebook在高峰期需要每秒提供100万张以上的图像。Haystack提供了一个比以前的通过NFS使用网络附加存储设备的方法开销更低，性能更高的解决方案。我们最重要的发现是这种传统意义上的设计将会因为元数据的查询导致过多的磁盘操作。我们小心的删减了每张照片中的元数据，这WHeystack存储机器就能在主存中执行元数据的查询了。这种选择节省了读取实际数据的磁盘操作，因而提高了整个系统的吞吐量。十二、AutomaticManagementofDataandComputationinDatacenters［数据中心的自动管理数据和计算］管理和计算数据是数据中心计算的核心。人工管理数据可能会导致数据丢失、存储设备的浪费和数据记账的劳动。缺乏合适的计算管理可能导致失去共享相同的跨多个作业的计算和计算结果增量的机会。Nectar被设计成解决上述问题的一个系统。它通过数据中心自动和统一管理数据和计算。在Nectar中，通过将数据和它的计算相关联，数据和计算被当作可互换的对象。派生的数据集，也就是计算的结果，被产生它们的程序唯一的识别，和它们程序一起都被全面的缓存服务自动管理。任何派生数据及都能通过重复执行它们的程序被透明的重新产生，并且任何计算都能使用过去缓存的数据呗透明的避免。这使得我们大大提高了数据中管理和资源的利用率：过时的和不常使用的派生数据集都会被自动的垃圾回收，共享的通用的计算只会被计算一次又能被其他程序重复使用。本文描述了Nectar的设计和实现，并对从几个生产集群和一个240个节点的实际部署中的日志记录进行分析研究撰写了系统的评估报告。十三、Large-scaleIncrementalProcessingUsingDistributedTransactionsandNotifications［使用分布式事务和通知的大规模的增量处理］当新的文档来到的时候更新网页的索引文件需要不断的转变大量的现有的文档库。由于一些小的，独立的改变而改变大型的数据存储是一类数据处理的一个例子。这种任务的存在是由于现有存储设施能力的差距。数据库不能满足这类任务的存储和吞吐量的需求：Google的索引系统存储了数以10PB的数据，数千台机器每天处理数10亿的更新。MapReduce（一种编程模型，用于大规模数据集（大于1TB）的并行运算）和其他的批处理系统不能独立的处理小量的更新，因为它们依赖于创建大型的批出来来获得效率。我们构建了Percolator，一个针对大型数据集的增量的处理更新的系统，并把它部署去创建Google网络搜索的索引。通过使用Percolator这种基于增量处理的索引系统替换基于批处理的索引系统，我们每天处理了相同数量的文档，但是使Google搜索中文档的平均生命减少50%。十四、Piccolo:BuildingFast,DistributedProgramswithPartitionedTables［使用分区表构建快速的分布式程序］Piccolo是一个新型的针对书写数据中心的并行内存应用的以数据为中心的编程模型。不想已有的数据流模型，Piccolo允许运行在不同的机器上的计算通过键值表接口来共享分布式的易变的状态。Piccolo允许有效的应用实现。特别的，应用程序可以自定义本地策略来利用本地的共享状态。Piccolo运行时使用用户定义的累积函数自动解决写-写冲突。在一系列的问题域上，我们使用Piccolo实现了应用程序，包括PageRank（页面排序）算法、K-means（K-均值）算法、分布式爬虫算法。实验使用了100个AmazonEC2［AmazonEC2（ElasticComputeCloud）是一个让用户可以租用云电脑运行所需应用的系统。］实例和12个机器集群。结果证明：针对很多问题，在提供相同容错保证和方便的编程接口时，Piccolo比以往的数据流模型更快。十五、ReiningintheOutliersinMap-ReduceClustersusingMantri［使用Mantri控制Map-Reduce集群的离群主机］针对Map-Reduce的集群操作的实验证明了离群主机极大延长了任务的完成。处理器的运行时抢占、内存，其他资源以及磁盘的错误、多种带宽、网络路径拥塞、任务负载不均衡都会导致离群。我们提出了Mantri，一个监视任务和利用原因，资源敏感技术来杀死离群主机的系统。Mantri的策略包括：重启离群主机和任务的网络敏感位置以及保护关键任务的输出。使用实时的进度报告，Mantri检测并在离群主机的生命周期中尽早的采取动作。尽早的行动释放那些可能被随后的任务使用的资源并能全面加快任务的整体性能。基于原因、资源、机会的动作使得Mantri提高了提前处理以后会重复执行的任务的性能。在Bing的产业集群上的部署以及痕迹驱动的模拟显示Mantri将任务完成的时间提高了32%。十六、TransactionalConsistencyandAutomaticManagementinanApplicationDataCache［在应用程序数据缓存的事务连续性和自动管理］分布式内存应用数据缓存就像内存缓存是解决数据库驱动的网络站点的流行方案。这些系统很容易添加到部署中，通过减少数据库服务器和应用服务器的负荷大大的提高了性能。不幸的是，这些缓存并没有与数据库和应用集成的很好。它们不能保事务在整个系统上的连续性，这就违反了底层数据库独立的性质。它们让应用负责定位保持缓存中的数据、程序复杂性的根源以及编程错误。为了解决这些问题，我们介绍一种事务缓存——TxCache，用简单的编程模型制作。TxCache保证任何数据都能使用事务看到，不管它是来自缓存还是数据库。TxCache反应了一个略微过期但是连续的数据库快照。TxCache通过简单的指定函数作为可缓存的方便的将缓存添加到应用中。它自动的缓存它们的结果，并且当底层的数据库改变时自动刷新缓存数据。我们的实验发现，添加TxCache将web应用的吞吐量增加了5.2倍。只是稍微比没有事务的缓存少了一点，证明了连续性不一定要以牺牲性能为代价。十七、AnAnalysisofLinuxScalabilitytoManyCores［分析Linux对多核的扩展性］本文分析了7个运行在48核计算机上Linux系统下的系统应用的扩展性(Exim,memcached,Apache,PostgreSQL,gmake,Psearchy,andMapReduce)。除了gmake，所有的应用都触发了当前Linux内核的扩展性瓶颈。使用最标准的并行编程技术本文介绍一种新的技术：SloppyCounters这些瓶颈可以从内核中移除，或者通过对应用的略微修改而避免。修改内核需要改变3002行代码。从分析中可以得到一个推测性的结论：到现在，在传统的操作系统组织上，还没有扩展性的原因可以放弃。十八、FlexSC:FlexibleSystemCallSchedulingwithException-LessSystemCalls［FlexSC：使用无异常的系统调用实现灵活的系统调用调度］在过去的30年里，系统调用已经是事实上的应用程序从操作系统内核请求服务的接口。当一个特殊的处理器指令是用来产生用户空间来执行内核时，系统调用几乎普遍被实现为同步机制。本文的第一部分，我们评估传统的同步的系统调用在系统密集任务负载上的性能影响。我们证明了同步系统调用对性能有显著的负面影响，主要是因为关键处理器结构的管道刷新和污染(例如：TLB和数据，指令缓存)。我们为应用程序向操作系统内核请求服务提出了一种新的机制：无异常系统调用。它们通过灵活调度操作系统的工作，反过来显著增加用户和内核空间的时间和空间性能来提高处理器的效率，因此减少了处理器结构的污染。无异常系统调用在多核处理器上尤其有效。他们主要的适用对象是高度并行的服务程序，例如Web服务器和数据库服务器。我们提出FlexSC,一个在Linux内核上实现的无异常系统调用和一个用户模式与POSIX线程标准二进制兼容的的线程包(FlexSC-Threads)，这使得将传统的同步系统调用转换为无异常的系统调用过程对于应用是透明的。我们在没有对应用做任何修改情况下，使用FlexSC将Apache的性能提高了116%，MySQL提高了40%，BIND提高了105%。十九、TrustandProtectionintheIllinoisBrowserOperatingSystem［Illinois浏览器操作系统的信任和保护］目前的web浏览器都很复杂，有大量的可信计算基础，并为黑客们提供了对现代计算机系统的轻松访问。本文我们介绍Illinois浏览器操作系统(IBOS)，一个为浏览者减少了可信计算新的新的操作系统和浏览器。在我们的架构中，我们把浏览器层抽象为最低的软件层，通过将直接将浏览器抽象影射到硬件抽象使得我们从可信计算模型中移除了几乎所有的传统的OS组件和服务。实验证明这种新的架构足够灵活，并允许新的浏览器安全策略，仍能支持传统的应用，而且不要要额外的开销啊就能获得全面的浏览体验。二十、StarTrackNextGeneration:AScalableInfrastructureforTrack-BasedApplications［下一代StarTrack：基于痕迹追踪的应用的扩展性结构］StarTrack是第一个被设计的管理GPS定位坐标轨迹的服务。这些坐标来源于移动设备，StarTrack方便了基于痕迹追踪应用的构造。我们起初试图用StarTrack构建一个实用的应用来发现大量可提高效率和扩展性的问题：比如频繁的CS往返、非必要的数据传输、涉及上千个痕迹的代价相似比较和低容错率。为了补充这些限制，我们修改了整个系统的架构、API和实现。API被扩展运行在痕迹的集合而不是单个痕迹上，延迟查询的执行以及允许缓存查询结果。一种新的数据结构一一痕迹树，被设计为能加速常规的相似痕迹的搜索操作。通过地图匹配算法将将每个痕迹转换为更多紧凑规范的路段序列。底层的痕迹数据库被分割复制到多个服务器上。所有被我们用新的API构造的应用确认的这些改变不仅简化了痕迹追踪程序的构造，还带来了客观的性能提高。比如，对相似痕迹的测量，在查询时间上有了2-3个数量级的改善。二十_、TaintDroid:AnInformation-FlowTrackingSystemforRealtimePrivacyMonitoringonSmartphones［智能手机实时隐私监控信息流追踪系统］今天的智能手机操作系统通常还是不能为用户提供对第三方应用使用它们私有数据的充分的控制和可见性。我们使用TaintDroid解决了这些弊端，它是一个高效的，系统级的动态污点痕迹追踪分析系统，这个系统能同时追踪多个源头的敏感数据。通过利用Android的虚拟化执行环境，TaintDroid提供实时的分析。TaintDroid在CPU绑定的微基准上的开销仅仅只有14%，在和第三方应用交互上的开销可以忽略不计。使用TaintDroid监视30个流行的Android第三方应用的行为，我们发现有20个应用的68个实例对用户的私有信息有潜在的误用。用TaintDroid监视敏感数据提供了在使用第三方应用时对用户的通知以及为智能手机安全公司提供识别不正常行为程序的有价值的信息。二十二、BuildingExtensibleNetworkswithRule-BasedForwarding［基于规则转发的可扩展网络的构建］我们提出一种网路设计来提供灵活和符合策略的转发。我们目标的核心围绕着一个新的架构理念：即数据包规则。这个规则是简单的if-then-else结构，它描述了网络应该或者不应该转发数据包的方式。数据包识别自己被转发的规则，路由器按照每个数据包自身关联的规则进行转发数据包。每个数据包的规则都被认证过，以保证在转发数据包的各个部分都符合包规则。包含未认证的数据包将会被网络简单的丢弃。我们对基于规则的转发（RBF）架构进行了设计，实现和评估。通过说明RBF支持多样的用例包括内容缓存，middlebox（类似网络地址转换NAT）选择和DDos（分布式拒绝服务攻击）保护，我们展示了它的灵活性。使用我们的原型路由实现，我们证明了RBF开销主要和现代的网络设备能力相关。二十三、CantheProductionNetworkBetheTestbed?［生产网络可以作为测试平台吗？］在计算机网络的研究中，验证始终是一个永久的问题。当决定怎样评估一个新的特性或者漏洞修复时，研究者或者操作者必须权衡实现（问题规模、实际用户流量、实际的设备）和开销（大量的金钱、实际用户流量像请求故障时间、实际设备像请求生产商制造可能需要数年）。构建一个真实的测试平台是很困难的，因为“真实”的网络发生在封闭的有专门硬件的商业交换机和路由器上。但是如果我们在软件交换机上构造测试平台的话，它们将会运行慢上好几个数量级。即使我们创建了真是的网络测试平台，但是它是专有目的的并且排除了常规的网络。他需要自己的位置，支持和专有链路。对于测试平台大的投入远远超过了绝大多数研究者的能力。本文我们介绍一种构建测试平台的方式，它是嵌入并和现有的网络共存的。这项技术体现在我们的第一个原型中——FlowVisor，它通过在控制层和数据层之间安放一个层次将网络硬件分割。我们证明了FlowVisor®过在他们自己的保护分割下的传统协议和研究者的实验将我们的生产网络分割。基本的想法是如果未修改的硬件支持一些基本的原语（在我们的原型中，OpenFlow，但是其他的也有可能），那么一个全球性的平台可以运行各种部署，而不会带来额外的开销。更进一步，我们评估了性能影响，并介绍了FlowVisor作为更广泛的评估平台的一部分怎样部署在7个其他大学。二十四、Onix:ADistributedControlPlatformforLarge-scaleProductionNetworks［大规模生产网络的分布式控制平台］计算机网络缺少一个通用的控制标准，作为传统的网络并没有提供内核网络级别的管理抽象。因此，每一个新的功能（比如路由），必须提供它自己的状态分发、元素发现和错误发现机制。我们相信这种通用控制的平台严重阻碍了灵活的、可靠的、未来丰富网络控制平台的发展。为了解决这个问题，我们提出了。nix，一个可以把网络控制平台实现为一个分布式系统的平台。控制层使用Onix编写并运行在网络的全局视角中，并使用平台提供的基本状态分发原语。因为Onix为控制层的实现提供了通用API允许他们，并允许他们在连续性，耐用性和可扩展性上做出权衡。二十五、AccountableVirtualMachines［负责虚拟机］本文我们提出AccountableVirtualMachines(AVMs)。像传统的虚拟机，AVM可以在一个计算机系统的虚拟拷贝上执行二进制软件映像。另外，它们记录不可抵赖的信息以允许审计人员最后检查软件是否按照期望行为。AVM提供很强的负责性，而这是很重要的。比如，在不同的主机和组织没必要相互信任的或者安装在第三方操作平台的软件的分布式系统中。AVM可以为未修改的二进制映像提供负责并不需要可靠的硬件。为了证明AVM是实用的，我们基于VMWareWorkstation设计实现了一个原型的AVM监视器，并使用他检测到了一个在线的多人游戏——CS的一些已有的欺骗行为。二十六、IntrusionRecoveryUsingSelectiveRe-execution［使用选择性重复执行的指令恢复］RETRO在攻击者危害了桌面系统和服务器后通过恢复攻击者的修改将系统修复，并以用户的最小参与维护了合法用户的行为。在正常的操作中，RETRO记录一个动作历史图(actionhistorygragh)，这是一个详细的描述系统执行的依赖关系图。RETRO使用refinement(精致)以多层的抽线来描述图对象和行为，这就允许了精细的依赖关系。在修复过程中，RETRO使用动作历史图来撤销不期望的动作，并通过回滚它的直接影响撤销不直接的影响，然后再重复执行受改变影响的合法动作。为了减少用户的参与和重复执行，RETRO使用预测和选择性重复执行那些因为攻击者改变而语义上受影响的动作，并使用补偿动作去解决额外的影响。用2个真实世界的攻击、2个合成的挑战性攻击和6个先前工作的的攻击对Linux下的RETRO原型进行评估，结果显示RETRO通常可以再不需要用户的参与下修复系统，并能从以前的解决中避免误报。这些好处来自按照工作量的计算的35-127%的执行时间开销和每天4-150G的日至空间为代价的。比如，HotCRP页面提交网站在SOSP2007年最后的前30分钟的工作量下慢了35%，并平均每天产生了4GB的日志。二十七、StaticCheckingofDynamically-VaryingSecurityPoliciesinDatabase-BackedApplications［数据库后台应用的动态多样性安全策略统计检查］我们实现了数据库后台应用的动态多样性安全策略统计检查系统。我们的估计检查访问控制和信息流策略的联系，策略依数据库的内容而改变。比如，一到多个数据库表可能代表一个数据控制矩阵，控制谁能读写这个表的项。使用符号化评估和自动定理证明，我们的估计统计性的检查这些策略，而不需要程序注释(除了策略本身)以及额外的运行时开销。规范来源于作为策略的SQL查询：比如：应用的保密策略是一组固定的查询，查询结果提供了和用户相关信息的上限。为了提供用户以来策略，我们允许查询依赖于用户知道的秘密。我们用原型的实现检查了一些如今常见的数据中心Web应用的代表性程序。二十八、Automatingconfigurationtroubleshootingwithdynamicinformationflowanalysis［用动态信息流分析的自动配置排错］软件的错误配置对于排错是既耗时又令人无比沮丧。本文我们通过针对配置错误的根本原因用动态数据流分析帮助解决这些问题。我们构造了一个叫ConfAid的工具，它对应用在二进制层次上监视程序执行的控制和数据流的因果依赖关系。ConAid使用这些依赖关系链接错误的行为和具体的配置文件记号。使用ConfAid解决OpenSSH、Apache和Post-fix的配置错误，能识别出错误配置原因作为第一或第二可能的根本原因的实验结果为：18个真实情况配置错误能识别出18个，60个随机产生的错误能识别55个。ConfAid仅仅需要运行几分钟，使得用它替代手工调试很有吸引力。二十九、EnablingConfiguration-IndependentAutomationbyNon-ExpertUsers［非专业用户独立配置自动化］Internet允许了前所未有的协作。Wikipedia，LuisVonAhn的ESP游戏以及reCAPTCHA（一个系统，让电脑去向人类求助）证明了传统的通过公司内部或者外包团队来执行任务可以被大量的Internet用户的代理所替代。这个成功的故事显示了源于人群执行任务的机遇，比如允许计算机用户帮助其他人回答像“如何让我的电脑做什么”的问题。然而，现在的通过人群执句T任务的方式限制了用户去文本描述任务解决方案，这既低效又令人沮丧。我们建议，允许大量的Internet计算机用户相互帮助，通过实际运行任务而不是对解决方案做文档说明来回答how-to之类的计算机问题。本文提出了KarDo,这个系统将运行在