DOCSLIB.ORG

Implementation and Evaluation of Transparent Fault-Tolerant Web Service with Kernel-Level Support

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Implementation and Evaluation of Transparent Fault-Tolerant Web Service with Kernel-Level Support Proceedings of the IEEE International Conference on Computer Communications and Networks Miami, Florida, pp. 63-68, October 2002. Implementation and Evaluation of Transparent Fault-Tolerant Web Service with Kernel-Level Support Navid Aghdaie and Yuval Tamir Concurrent Systems Laboratory UCLA Computer Science Department Los Angeles, California 90095 {navid,tamir}@cs.ucla.edu AbstractÐMost of the techniques used for increasing the 1 2 availability of web services do not provide fault tolerance for requests being processed at the time of server failure. Other schemes require deterministic servers or changes to the web Client Web Server Back-end client. These limitations are unacceptable for many current and future applications of the Web. We have developed an efficient 4 3 implementation of a client-transparent mechanism for providing fault-tolerant web service that does not have the limitations Figure 1: If the web server fails before sending the client reply (step mentioned above. The scheme is based on a hot standby backup 4), the client can not determine whether the failure was before or server that maintains logs of requests and replies. The after the web server communication with the back-end (steps 2,3) implementation includes modifications to the Linux kernel and to web browser, are widely distributed and they are typically the Apache web server, using their respective module mechanisms. We describe the implementation and present an developed independently of the web service, it is critical that evaluation of the impact of the backup scheme in terms of any fault tolerance scheme used be transparent to the client. throughput, latency, and CPU processing cycles overhead. Schemes for transparent server replication [3, 7, 18, 25] sometimes require deterministic servers for reply generation I. INTRODUCTION or do not recover requests whose processing was in progress Web servers are increasingly used for critical applications at the time of failure. We discuss some of these solutions in where outages or erroneous operation are unacceptable. In more detail in Sections II and V. most cases critical services are provided using a three tier We have previously developed a scheme for client- architecture, consisting of: client web browsers, one or more transparent fault-tolerant web service that overcomes the replicated front-end servers (e.g. Apache), and one or more disadvantages of existing schemes [1]. The scheme is based back-end servers (e.g. a database). HTTP over TCP/IP is the on logging of HTTP requests and replies to a hot standby predominant protocol used for communication between clients backup server. Our original implementation was based on and the web server. The front-end web server is the mediator user-level proxies, required non-standard features of the between the clients and the back-end server. Solaris raw socket interface, and was never intergrated with a Fault tolerance techniques are often used to increase the real web server. That implementation did not require any reliability and availability of Internet services. Web servers kernel modifications but incurred high processing overhead. are often stateless Ð they do not maintain state information The contribution of this paper is a more efficient from one client request to the next. Hence, most existing web implementation of the scheme on Linux based on kernel server fault tolerance schemes simply detect failures and route modifications and its integration with the Apache web server future requests to backup servers. Examples of such fault using Apache's module mechanism. The small modifications tolerance techniques include the use of specialized routers and to the kernel are used to provide client-transparent multicast of load balancers [4, 5, 12, 14] and data replication [6, 28]. These requests to a primary server and a backup server as well as the methods are unable to recover in-progress requests since, ability to continue transmission of a reply to the client despite while the web server is stateless between transactions, it does server failure. Our implementation is based on off-the-shelf maintain important state from the arrival of the first packet of hardware (PC, router), and software (Linux, Apache). We a request to the transmission of the last packet of the reply. rely on the standard reliability features of TCP and do not With the schemes mentioned above, the client never receives make any changes to the protocol or its implementation. complete replies to the in-progress requests and has no way to In Section II we present the architecture of our scheme and determine whether or not a requested operation has been key design choices. Section III discusses our implementation performed [1, 15, 16] (see Figure 1). based on kernel and web server modules. A detailed analysis Some recent work does address the need for handling in- of the performance results including throughput, latency, and progress transactions. Client-aware solutions such consumed processing cycles is presented in Section IV. as [16, 23, 26] require modifications to the clients to achieve Related work is discussed in Section V. their goals. Since many versions of the client software, the 63 II. TRANSPARENT FAULT-TOLERANT WEB SERVICE We have previously proposed [1] implementing transparent In order to provide client-transparent fault-tolerant web fault-tolerant web service using a hot standby backup server service, a fault-free client must receive a valid reply for every that logs HTTP requests and replies but does not actually request that is viewed by the client as having been delivered. process requests unless the primary server fails. The error Both the request and the reply may consist of multiple TCP control mechanisms of TCP are used to provide reliable packets. Once a request TCP packet has been acknowledged multicast of client requests to the primary and backup. All to the client, it must not be lost. All reply TCP packets sent to client request packets are logged at the backup before arriving the client must form consistent, correct replies to prior at the primary and the primary reliably forwards a copy of the requests. reply to the backup before sending it to the client. Upon failure of the primary, the backup seamlessly takes over We assume that only a single server host at a time may fail. receiving partially received requests and transmitting logged We further assume that hosts are fail-stop [24]. Hence, host replies. The backup processes logged requests for which no failure is detected using standard techniques, such as periodic reply has been logged and any new requests. heartbeats. Techniques for dealing with failure modes other than fail-stop are important but are beyond the scope of this Since our scheme is client-transparent, clients communicate paper. We also assume that the local area network connecting with a single server address (the advertised address) and are the two servers as well as the Internet connection between the unaware of server replication [1]. The backup server receives client and the server LAN will not suffer any permanent all the packets sent to the advertised address and forwards a faults. The primary and backup hosts are connected on the copy to the primary server. For client transparency, the source same IP subnet. In practice, the reliability of the network addresses of all packets received by the client must be the connection to that subnet can be enhanced using multiple advertised address. Hence, when the primary sends packets to routers running protocols such as the Virtual Router the clients, it ``spoofs'' the source address, using the service's Redundancy Protocol [19]. This can prevent the local LAN advertised address instead of it's own as the source address. router from being a critical single point of failure. The primary logs replies by sending them to the backup over a reliable (TCP) connection and waiting for an acknowledgment In order achieve the fault tolerance goals, active replication before sending them to the client. This paper uses the same of the servers may be used, where every client request is basic scheme but the focus here is on the design and processed by both servers. While this approach will have the evaluation of a more efficient implementation based on kernel best fail-over time, it suffers from several drawbacks. First, modifications. this approach has a high cost in terms of processing power, as every client request is effectively processed twice. A second III. IMPLEMENTATION drawback is that this approach only works for deterministic There are many different ways to implement the scheme servers. If the servers generate replies non-deterministically, described in Section II. As mentioned earlier, we have the backup may not have an identical copy of a reply and thus previously done this based on user-level proxies, without any it can not always continue the transmission of a reply should kernel modifications [1]. A proxy-based implementation is the primary fail in the midst of sending a reply. simpler and potentially more portable than an implementation An alternative approach is based on logging. Specifically, that requires kernel modification but it incurs higher request packets are acknowledged only after they are stored performance overhead (Section IV). It is also possible to redundantly (logged) so that they can be obtained even after a implement the scheme entirely in the kernel in order to failure of a server host [1, 3]. Since the server may be non- minimize the overhead [22]. However it is generally desirable deterministic, none of the packets of a reply can be sent to the to minimize the complexity of the kernel [8, 17]. Furthermore, client unless the entire reply is safely stored (logged) so that the more modular approach described in this paper makes it its transmission can proceed despite a failure of a server easier to port the implementation to other kernels or other web host [1].
Load more

Recommended publications
  • Linux Performance Tools
    Linux Performance Tools Brendan Gregg Senior Performance Architect Performance Engineering Team [email protected] @brendangregg This Tutorial • A tour of many Linux performance tools – To show you what can be done – With guidance for how to do it • This includes objectives, discussion, live demos – See the video of this tutorial Observability Benchmarking Tuning Stac Tuning • Massive AWS EC2 Linux cloud – 10s of thousands of cloud instances • FreeBSD for content delivery – ~33% of US Internet traffic at night • Over 50M subscribers – Recently launched in ANZ • Use Linux server tools as needed – After cloud monitoring (Atlas, etc.) and instance monitoring (Vector) tools Agenda • Methodologies • Tools • Tool Types: – Observability – Benchmarking – Tuning – Static • Profiling • Tracing Methodologies Methodologies • Objectives: – Recognize the Streetlight Anti-Method – Perform the Workload Characterization Method – Perform the USE Method – Learn how to start with the questions, before using tools – Be aware of other methodologies My system is slow… DEMO & DISCUSSION Methodologies • There are dozens of performance tools for Linux – Packages: sysstat, procps, coreutils, … – Commercial products • Methodologies can provide guidance for choosing and using tools effectively • A starting point, a process, and an ending point An#-Methodologies • The lack of a deliberate methodology… Street Light An<-Method 1. Pick observability tools that are: – Familiar – Found on the Internet – Found at random 2. Run tools 3. Look for obvious issues Drunk Man An<-Method • Tune things at random until the problem goes away Blame Someone Else An<-Method 1. Find a system or environment component you are not responsible for 2. Hypothesize that the issue is with that component 3. Redirect the issue to the responsible team 4.
    [Show full text]
  • Why Open Source Software?
    Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! David A. Wheeler http://www.dwheeler.com/contactme.html Revised as of November 7, 2004 This paper provides quantitative data that, in many cases, using open source software / free software is a reasonable or even superior approach to using their proprietary competition according to various measures. This paper’s goal is to show that you should consider using OSS/FS when acquiring software. This paper examines market share, reliability, performance, scalability, security, and total cost of ownership. It also has sections on non- quantitative issues, unnecessary fears, OSS/FS on the desktop, usage reports, governments and OSS/FS, other sites providing related information, and ends with some conclusions. An appendix gives more background information about OSS/FS. You can view this paper at http://www.dwheeler.com/oss_fs_why.html (HTML format). Palm PDA users may wish to use Plucker to view this. A short briefing based on this paper is also available in PDF and Open Office Impress formats (for the latter, use Open Office Impress). Old archived copies and a list of changes are also available. 1. Introduction Open Source Software / Free Software (OSS/FS) has risen to great prominence. Briefly, OSS/FS programs are programs whose licenses give users the freedom to run the program for any purpose, to study and modify the program, and to redistribute copies of either the original or modified program (without having to pay royalties to previous developers). This goal of this paper is to show that you should consider using OSS/FS when you’re looking for software, based on quantitative measures.
    [Show full text]
  • Linux Certification Bible.Pdf
    Turn in: .75 Board: 7.0625 .4375 VISIBLE SPINE = 1.75 .4375 Board: 7.0625 Turn in: .75 The only guide you need for Linux+ exam success . “This is the all-inclusive Linux+ guide you’ve been looking for.” You’re holding in your hands the most comprehensive and effective guide available for the CompTIA Linux+ 100% — Tim Sosbe, Editorial Director, Certification Magazine COMPREHENSIVE 100% exam. Trevor Kay delivers incisive, crystal-clear explanations of every Linux+ topic, highlighting exam- ONE HUNDRED PERCENT critical concepts and offering hands-on tips that can help you in your real-world career. Throughout, he COMPREHENSIVE Covers CompTIA Linux+ AUTHORITATIVE provides pre-tests, exam-style assessment questions, and scenario problems — everything you need to Exam XK0-001 WHAT YOU NEED master the material and pass the exam. ONE HUNDRED PERCENT Inside, you’ll find complete coverage Linux+ of Linux+ exam objectives Linux+ Master the • Get up to speed on Linux basics and understand the differences material for the between different Linux distributions CompTIA Linux+ • Tackle Linux installation, from planning to network configuration, Exam XK0-001 dual-boot systems, and upgrades Test your knowledge • Get the scoop on managing Linux disks, file systems, and with assessment processes; implementing security; and backing up your system Hundreds of unique, exam-like questions give you a random set of questions each questions and • Learn the ins and outs of configuring the X Window time you take the exam. scenario problems system and setting up a network • Find out how to establish users and groups, navigate Practice on the Linux file system, and use Linux system commands A customizable format enables state-of-the-art • Delve into troubleshooting techniques for the boot you to define test-preparation process, software, and networking your own software preferences • Get a handle on maintaining system hardware, from for question CPU and memory to peripherals presentation.
    [Show full text]
  • Instant OS Updates Via Userspace Checkpoint-And
    Instant OS Updates via Userspace Checkpoint-and-Restart Sanidhya Kashyap, Changwoo Min, Byoungyoung Lee, and Taesoo Kim, Georgia Institute of Technology; Pavel Emelyanov, CRIU and Odin, Inc. https://www.usenix.org/conference/atc16/technical-sessions/presentation/kashyap This paper is included in the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16). June 22–24, 2016 • Denver, CO, USA 978-1-931971-30-0 Open access to the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16) is sponsored by USENIX. Instant OS Updates via Userspace Checkpoint-and-Restart Sanidhya Kashyap Changwoo Min Byoungyoung Lee Taesoo Kim Pavel Emelyanov† Georgia Institute of Technology †CRIU & Odin, Inc. # errors # lines Abstract 50 1000K 40 100K In recent years, operating systems have become increas- 10K 30 1K 20 ingly complex and thus more prone to security and per- 100 formance issues. Accordingly, system updates to address 10 10 these issues have become more frequently available and 0 1 increasingly important. To complete such updates, users 3.13.0-x 3.16.0-x 3.19.0-x May 2014 must reboot their systems, resulting in unavoidable down- build/diff errors #layout errors Jun 2015 time and further loss of the states of running applications. #static local errors #num lines++ We present KUP, a practical OS update mechanism that Figure 1: Limitation of dynamic kernel hot-patching using employs a userspace checkpoint-and-restart mechanism, kpatch. Only two successful updates (3.13.0.32 34 and → which uses an optimized data structure for checkpoint- 3.19.0.20 21) out of 23 Ubuntu kernel package releases.
    [Show full text]
  • How to Install Xenomai?
    How to install Xenomai? This tutorial will detail Xenomai installation on a small Dell Optiplex 990 desktop having 16GB of RAM and an Intel Core i7-2600 CPU @ 3.40GHz × 8 cores. The machine has two 128GB Samsung SSD's. For the Ubuntu installation, 100GB of the first drive was dedicated to the operating system (mount point /) and the rest was left as swap space. On the second drive, 75GB was dedicated to user home directories (mount point /Volumes/<computer_name>) and the rest was left to backup space (mount point /Volumes/backup). 1 Step-by-step guide for Installing Linux 3.8.13 + Xenomai 2.6.3 (Ubuntu 12.04) 1.1 Prerequisites 1.2 Building a Xenomai-patched Linux kernel package 1.2.1 Downloading the sources/configuring xenomai 1.2.2 Kernel configuration and compilation 1.2.3 Testing for latency issues 1.2.4 Graphics drivers and Xenomai 1.2.4.1 NVIDIA GF119 1.2.4.2 Intel Onboard Graphics i915 1.3 Installing RT-NET 1.3.1 Downloading and installation 1.3.2 Network configuration 1.3.3 Running RTNet 1.3.4 Running RTNet at startup (optional) 1.3.5 Testing RTNet (on the SARCOS robot) 1.4 Installing usb4rt 1.4.1 Background 1.4.2 Installation 1.4.3 Configuration 1.4.4 Resolving IRQ sharing 1.4.5 Running usb4rt 1.4.6 Running usbrt at startup (optional) 1.4.7 Using usb4rt with more than one device 1.4.8 Testing usb4rt 1.4.9 Debugging usb4rt 1.5 Issue Log 1.6 Random Notes: 1.6.1 Reinstalling Ubuntu while preserving partitions 1.6.2 Solving the "invalid arch independent ELF magic" GRUB issue 1.6.3 SSH woes Step-by-step guide for Installing Linux 3.8.13
    [Show full text]
  • Speculative Use of Idle Resources Ph.D
    Speculative Use of Idle Resources Ph.D. Dissertation Proposal Lars Eggert [email protected] Computer Science Department University of Southern California Los Angeles, CA 90089-0781 USA October 22, 2001 (Appendices added July 2, 2002) Abstract Even a fully loaded computer system, where the bottleneck resource is constantly busy, often has some idle capacities available on other resources. This proposal argues for using these idle ca- pacities speculatively, increasing system performance for correct predictions. In such a system, all resources will ideally be constantly loaded with either regular foreground tasks, or speculative idle-time tasks. The key contribution of this proposal is a model for non-interfering use of idle resource capacity, based on three principles: resource prioritization between regular foreground and idle-time use, preemptability of idle-time processing, and isolation of speculative side effects. Current operating systems fail to provide all three capabilities. Without new mechanisms, processing of speculative tasks can delay or even starve foreground processing, and result in a decreased foreground per- formance, instead of increasing it. Under the proposed model, speculative tasks only execute using otherwise idle resource capaci- ties; the model also shields foreground processing from the side effects of their presence in the system. Thus, speculation can no longer delay or interfere with foreground processing. Based on the model, a proof-of-concept design of network extensions for idle-time service can isolate fore- ground network packets from the presence of idle-time traffic to within 1-2% throughput. The remainder of this thesis will focus on idle-time support for the network file system (NFS).
    [Show full text]
  • Developing a Solution for Multimedia Home Networking
    Peng Liu Developing a Solution for Multimedia Home Networking School of Electrical Engineering Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 20.5.2015 Thesis supervisor: Prof. Raimo A. Kantola Thesis advisor: PhD Mikko Välimäki aalto university abstract of the school of electrical engineering master’s thesis Author: Peng Liu Title: Developing a Solution for Multimedia Home Networking Date: 20.5.2015 Language: English Number of pages: 9+66 Department of Communications and Networking Professorship: Networking Technology Code: S-38 Supervisor: Prof. Raimo A. Kantola Advisor: PhD Mikko Välimäki In recent years, the rapid development of electronics and computer science has enabled home networking devices to become more affordable and more powerful. Several widely used multimedia-streaming solutions have become available in the market. However, as a result of their different technical designs, these standards naturally experience serious compatibility issues. Thus, end users can have several multimedia devices, with each one using a distinctive, unique protocol, making it challenging or even impossible sometimes to share media between those devices. These compatibility issues have motivated the need to determine the technological features common to the existing multimedia-streaming standards and to develop a more easy-to-use multimedia home networking solution. This thesis compares the modern solutions for multimedia home networking (MHN), including AirPlay, Miracast, Chromecast, and especially the Digital Liv- ing Network Alliance (DLNA) standard due to its wide adoption. By conducting research on the features and capabilities of these existing solutions, a suitable mo- bile solution for MHN, which takes advantage of AirPlay, Discovery and Launch (DIAL), and DLNA, is proposed for the Android platform.
    [Show full text]
  • Why Open Source Software / Free Software (OSS/FS, FLOSS, Or FOSS)? Look at the Numbers!
    Translations available: Czech | French | Japanese | Spanish Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! David A. Wheeler http://www.dwheeler.com/contactme.html Revised as of July 18, 2015 This paper (and its supporting database) provides quantitative data that, in many cases, using open source software / free software (abbreviated as OSS/FS, FLOSS, or FOSS) is a reasonable or even superior approach to using their proprietary competition according to various measures. This paper’s goal is to show that you should consider using OSS/FS when acquiring software. This paper examines popularity, reliability, performance, scalability, security, and total cost of ownership. It also has sections on non-quantitative issues, unnecessary fears, OSS/FS on the desktop, usage reports, governments and OSS/FS, other sites providing related information, and ends with some conclusions. An appendix gives more background information about OSS/FS. You can view this paper at http://www.dwheeler.com/oss_fs_why.html (HTML format). A short presentation (briefing) based on this paper is also available. Palm PDA users may wish to use Plucker to view this longer report. Old archived copies and a list of changes are also available. 1. Introduction Open Source Software / Free Software (aka OSS/FS), also described as Free/Libre and Open Source Software (FLOSS), has risen to great prominence. Briefly, FLOSS programs are programs whose licenses give users the freedom to run the program for any purpose, to study and modify the program, and to redistribute copies of either the original or modified program (without having to pay royalties to previous developers).
    [Show full text]
  • The TUX Web Server
    CITI Technical Report 00-8 An analysis of the TUX web server Chuck Lever, Sun-Netscape Alliance [email protected] Marius Aamodt Eriksen, Linux.com [email protected] Stephen P. Molloy, University of Michigan [email protected] ABSTRACT We report on a high-performance in-kernel web server for Linux known as the Threaded linUX http layer, or TUX, for short. TUX uses aggressive network layer data caching to accelerate static content delivery, and invokes CGI scripts directly from the kernel to accelerate dynamic content generation. We describe the TUX web server architecture, modifications included in the patch, and how they affect kernel operation and web server performance. November 16, 2000 Center for Information Technology Integration University of Michigan 519 West William Street Ann Arbor, MI 48103-4943 This document was written as part of the Linux Scalability Project. The work described in this paper was supported via grants from the Sun-Netscape Alliance, Intel, Dell, and IBM. For more information, see our home page. If you have comments or suggestions, email <[email protected]> Copyright © 2000 by the Regents of the University of Michigan, and by AOL-Netscape Inc. All rights reserved. Trademarked material referenced in this document is copyright by its respective owner. An analysis of the TUX web server Chuck Lever, Sun-Netscape Alliance [email protected] Marius Aamodt Eriksen, Linux.com [email protected] Stephen P. Molloy, University of Michigan [email protected] 1. Introduction • Driving the web server directly from the kernel’s networking layer to create a truly network event- As the demand for faster and more scalable web driven server service increases, system designers have discovered ways to improve web server performance and • Caching complete responses in the kernel’s scalability by integrating web server functionality networking layer to accelerate static content into operating systems.
    [Show full text]
  • 1 111111 111111111111111111111111111111 11111 1111 Iii 10.25.2011
    TTAB KARL R. CANNON (Registration No. 36,468) BRETT J. DAVIS (Registration No. 46,655) CLAYTON, HOWARTH & CANNON, P.C. 6965 Union Park Center, Suite 400 Cottonwood Heights, Utah 84047 P.O. Box 1909 Sandy, Utah 84091-1909 Telephone: (801) 255-5335 Facsimile: (801) 255-5338 Attorneys for Connect Public Relations, Inc. Opposed Mark: CONNECT U.S. Trademark Application Serial Number: 77/714,693 Published: March 2, 2010 IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE TRADEMARK TRIAL AND APPEAL BOARD CONNECT PUBLIC RELATIONS, INC., a Utah corporation, NOTICE OF WITHDRAWAL OF Opposer MOTION FOR PARTIAL SUMMARY JUDGMENT MAILED V. OCTOBER 17, 2011 DIGITALMOJO, INC., a California corporation, Opposition No. 91196299 Applicant. Opposer Connect Public Relations, Inc. ("ConnectPR" or "Opposer") hereby gives notice of the withdrawal of its Motion for Partial Summary Judgement ("Motion") having a certificate of deposit dated October 17, 2011. The reason for the withdrawal is that page 2 of the Motion Certificate of Deposit Under 37 C.F.R. § 2.197 I hereby certify that this correspondence is being deposited with the United States Postal Service ai.prst class mail, postage prepaid, in an envelope addressed to Trademark Trial and Appeal Board, P.O. Box 1451, Alexandria, Virginia 22313-1451, on the I day of Oc 2011. Karl R. annon Attorney Registration No. 36,468 Attorney for Applicant 1 111111 111111111111111111111111111111 11111 1111 III 10.25.2011 . Pat Ent 1 T,"101:171 118 inadvertently included a large blank portion when printed that caused the Motion to exceed the page limit set by the Board.
    [Show full text]
  • On the Design of Reliable and Scalable Networked Systems
    On the Design of Reliable and Scalable Networked Systems Ph.D. Thesis Tomas Hruby VU University Amsterdam, 2014 This work was funded by European Research Council under ERC Advanced Grant 227874. Copyright © 2014 by Tomas Hruby. ISBN 978-90-5383-072-7 Printed by Wöhrmann Print Service. VRIJE UNIVERSITEIT ON THE DESIGN OF RELIABLE AND SCALABLE NETWORKED SYSTEMS ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr. F.A. van der Duyn Schouten, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de Faculteit der Exacte Wetenschappen op donderdag 10 april 2014 om 13.45 uur in de aula van de universiteit, De Boelelaan 1105 door TOMAS HRUBY geboren te Stod, Tsjechische Republiek promotors: prof.dr. Andrew S. Tanenbaum prof.dr. Herbert Bos Acknowledgements Tomas Hruby Amsterdam, The Netherlands, December 2013 v Contents Acknowledgements v Contents vii List of Figures xi List of Tables xiii Publications xv 1 Introduction 1 1.1 Overview of Operating System Architectures . 4 1.1.1 Monolithic Kernels . 4 1.1.2 Microkernels . 5 1.2 New Multicore Hardware . 7 1.3 Network Stack . 9 1.4 NEWTOS ............................... 11 1.5 Contributions . 12 1.6 Organization of the Dissertation . 12 2 Keep Net Working On a Dependable and Fast Networking Stack 15 2.1 Introduction . 16 2.2 Reliability, performance and multicore . 17 2.3 Rethinking the Internals . 19 2.3.1 IPC: What’s the kernel got to do with it? . 19 2.3.2 Asynchrony for Performance and Reliability .
    [Show full text]
  • Appendix References
    VU Research Portal On the design of reliable and scalable networked systems Hruby, T. 2016 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Hruby, T. (2016). On the design of reliable and scalable networked systems. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 29. Sep. 2021 References [1] ASLR: Leopard versus Vista. http://blog.laconicsecurity.com/ 2008/01/aslr-leopard-versus-vista.html. [2] ARM - big.LITTLE Processing. http://www.arm.com/products/ processors/technologies/biglittleprocessing.php. [3] Killing the Big Kernel Lock. http://lwn.net/Articles/380174/. [4] Network transmit queue limits. http://lwn.net/Articles/454390/. [5] D-Bus. http://dbus.freedesktop.org. [6] The Heartbleed Bug. http://heartbleed.com/. [7] httperf. http://www.hpl.hp.com/research/linux/httperf/.
    [Show full text]