DOCSLIB.ORG

The Battle of the Event Loops Copy 2

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Battle of the Event Loops Copy 2 The battle of the event loops Ujjwal Sharma (@ryzokuken) featuring Olga Kobets (@homyasusina) 1 Ujjwal Sharma (he/him) • Compilers Hacker at Igalia • Node.js Core Collaborator • TC39 Delegate • Work on V8 and Cranelift (Spidermonkey/wasmtime) • Student • Speaker 2 @ryzokuken ft. @homyasusina Барсик B1000 3 @ryzokuken ft. @homyasusina The event loop has to be one of the most talked about subjects in JavaScript 4 @ryzokuken ft. @homyasusina Let’s dig a little deeper. 5 @ryzokuken ft. @homyasusina Section I Concurrency 6 @ryzokuken ft. @homyasusina Concurrency vs Parallelism Concurrency 7 @ryzokuken ft. @homyasusina Concurrency /kənˈkʌr(ə)nsi/ noun When two or more tasks can start, run, and complete in overlapping time periods. Concurrency 8 @ryzokuken ft. @homyasusina Example: multitasking on a single-core machine Concurrency 9 @ryzokuken ft. @homyasusina Concurrency 10 @ryzokuken ft. @homyasusina Parallelism /ˈparəlɛlɪzəm/ noun The state of being parallel or of corresponding in some way. Concurrency 11 @ryzokuken ft. @homyasusina Example: the Greek thinkers used to believe in the parallelism of microcosm and macrocosm Concurrency 12 @ryzokuken ft. @homyasusina � Concurrency 13 @ryzokuken ft. @homyasusina Parallelism /ˈparəlɛlɪzəm/ noun When tasks literally run at the same time. Concurrency 14 @ryzokuken ft. @homyasusina Example: a multicore processor Concurrency 15 @ryzokuken ft. @homyasusina Concurrency 16 @ryzokuken ft. @homyasusina If computation is said to be concurrent, then it doesn't necessarily dictate how the concurrency is achieved under the hood. Concurrency 17 @ryzokuken ft. @homyasusina JavaScript is single-threaded Concurrency 18 @ryzokuken ft. @homyasusina V8 is single-threaded Concurrency 19 @ryzokuken ft. @homyasusina “There are many who pretend to despise and belittle that which is beyond their reach.” – Aesop (Aesop’s Fables) Concurrency 20 @ryzokuken ft. @homyasusina JavaScript does not need multithreading Concurrency 21 @ryzokuken ft. @homyasusina Two main reasons for operations to be time-consuming: 1. Operations that perform heavy computation. 2. Operations that depend on something. Concurrency 22 @ryzokuken ft. @homyasusina Two main reasons for operations to be time-consuming: 1. Operations that require CPU time. 1. Operations that perform heavy computation. 2. Operations that wait for something. 2. Operations that depend on something. Concurrency 23 @ryzokuken ft. @homyasusina 99% of all applications do nothing 99% of the time Concurrency 24 @ryzokuken ft. @homyasusina Multithreading is useful when 1. Significant CPU time is required. 2. Need to call an awkward synchronous (blocking) API. Concurrency 25 @ryzokuken ft. @homyasusina Node.js const cluster = require("cluster") const workers = require("worker_threads") Concurrency 26 @ryzokuken ft. @homyasusina Deno const worker = new Worker(...) Concurrency 27 @ryzokuken ft. @homyasusina So how do you use single-threaded concurrency in the real world? Concurrency 28 @ryzokuken ft. @homyasusina Section II Asynchronous Programming 29 @ryzokuken ft. @homyasusina Asynchrony /eɪˈsɪŋ krəˌni/ noun The occurrence of events independent of the main program flow and ways to deal with such events. Asynchronous Programming 30 @ryzokuken ft. @homyasusina Event-driven programming is by far the most popular paradigm to achieve asynchrony Asynchronous Programming 31 @ryzokuken ft. @homyasusina Green Threads is a popular alternative Asynchronous Programming 32 @ryzokuken ft. @homyasusina We’re not the first ones to use event-driven systems to build web servers Asynchronous Programming 33 @ryzokuken ft. @homyasusina • .NET (C#) • Spark (Java) • Twisted (Python) • Express (JavaScript) • Vapor (Swift) • Rocket (Rust) Asynchronous Programming 34 @ryzokuken ft. @homyasusina JavaScript has a concurrency model based on an event loop Asynchronous Programming 35 @ryzokuken ft. @homyasusina Asynchronous Programming 36 @ryzokuken ft. @homyasusina What the heck is the event loop anyway? | Philip Roberts | JSConf EU Asynchronous Programming 37 @ryzokuken ft. @homyasusina Иван Тулуп: асинхронщина в JS под капотом / Михаил Башуров (Luxoft) Asynchronous Programming 38 @ryzokuken ft. @homyasusina But the “event loop” is a theoretical model Asynchronous Programming 39 @ryzokuken ft. @homyasusina Section III Event Loops 40 @ryzokuken ft. @homyasusina poll and select • History: Introduced in the ~80s-90s (old). • Functionality: More or less the same (boring). • Speed: Perform similarly on benchmarks (slow). 1983 • Portability: Everywhere (nice). • Complexity: As simple as it gets (neat). Event Loops 41 @ryzokuken ft. @homyasusina Result: libevent 2000 Event Loops 42 @ryzokuken ft. @homyasusina People loved poll • epoll • /dev/poll • kqueue • pollset • inotify Event Loops 43 @ryzokuken ft. @homyasusina Result: libevent 2003 Event Loops 44 @ryzokuken ft. @homyasusina Result: libevent* 2005 * Slightly Faster Event Loops 45 @ryzokuken ft. @homyasusina Problem: libevent is too… Event Loops 46 @ryzokuken ft. @homyasusina Problem: libevent is too… bloated Event Loops 47 @ryzokuken ft. @homyasusina Result: libev 2007 Event Loops 48 @ryzokuken ft. @homyasusina Event Loops 49 @ryzokuken ft. @homyasusina Node Standard Library Node Bindings Thread Pool Event Loop V8 (libeio) (libev) Event Loops 50 @ryzokuken ft. @homyasusina Narrator: There was a problem. Event Loops 51 @ryzokuken ft. @homyasusina Event Loops 52 @ryzokuken ft. @homyasusina Enter the Dragon Event Loops 53 @ryzokuken ft. @homyasusina Enter the Unicorn Velociraptor 2013 Event Loops 54 @ryzokuken ft. @homyasusina Event Loops 55 @ryzokuken ft. @homyasusina LXJS 2012 - Bert Belder - libuv Event Loops 56 @ryzokuken ft. @homyasusina Node Standard Library Node Bindings Thread Pool Event Loop V8 (libeio) (libev) Event Loops 57 @ryzokuken ft. @homyasusina Node Standard Library Node Bindings V8 libuv Event Loops 58 @ryzokuken ft. @homyasusina Event Loops 59 @ryzokuken ft. @homyasusina Section IV Into the boxing ring 60 @ryzokuken ft. @homyasusina The lifesaver: autocannon • wrk and wrk2 • “It’s just JavaScript” • “It just works” • mcollina is a legend • TCP? • Fake TCP? Into the boxing ring 61 @ryzokuken ft. @homyasusina Introducing gandiva Into the boxing ring 62 @ryzokuken ft. @homyasusina Let the benchmarking begin! Into the boxing ring 63 @ryzokuken ft. @homyasusina Section V Conclusion 64 @ryzokuken ft. @homyasusina Conclusion 1: tokio is slow Conclusion 65 @ryzokuken ft. @homyasusina Conclusion 66 @ryzokuken ft. @homyasusina Conclusion 2: deno is slow Conclusion 67 @ryzokuken ft. @homyasusina Deno's design is different than Node's in that all native calls are done through zero-copy message passing. This allows for a more uniform bindings, where we have centralised understanding of all calls being made out of the VM. – Ryan Dahl Conclusion 68 @ryzokuken ft. @homyasusina Ultimately we expect this design to result in better performance, but we're not there yet. Deno's networking is about 50% the speed of Node v13. Follow our progress at https:// deno.land/benchmarks – Ryan Dahl Conclusion 69 @ryzokuken ft. @homyasusina Conclusion 3: people are still reluctant Conclusion 70 @ryzokuken ft. @homyasusina Conclusion 71 @ryzokuken ft. @homyasusina But it’s getting there! Conclusion 72 @ryzokuken ft. @homyasusina Introducing Deno 1.0 Conclusion 73 @ryzokuken ft. @homyasusina Special Thanks • Artem Kobzar • Ryan Dahl • Olga Kobets • Kamil Mysliwiec Conclusion 74 @ryzokuken ft. @homyasusina спасибо! Conclusion 75 @ryzokuken ft. @homyasusina.
Load more

Recommended publications
  • Knot DNS Resolver Release 1.2.0
    Knot DNS Resolver Release 1.2.0 CZ.NIC Labs Apr 25, 2017 Contents 1 Building project 3 1.1 Installing from packages.........................................3 1.2 Platform considerations.........................................3 1.3 Requirements...............................................3 1.4 Building from sources..........................................5 1.5 Getting Docker image..........................................7 2 Knot DNS Resolver library 9 2.1 Requirements...............................................9 2.2 For users.................................................9 2.3 For developers..............................................9 2.4 Writing layers.............................................. 11 2.5 APIs in Lua................................................ 12 2.6 API reference............................................... 15 3 Knot DNS Resolver daemon 47 3.1 Enabling DNSSEC............................................ 47 3.2 CLI interface............................................... 48 3.3 Scaling out................................................ 48 3.4 Running supervised........................................... 49 3.5 Configuration............................................... 49 3.6 Using CLI tools............................................. 64 4 Knot DNS Resolver modules 67 4.1 Static hints................................................ 67 4.2 Statistics collector............................................ 69 4.3 Query policies.............................................. 71 4.4 Views and ACLs............................................
    [Show full text]
  • Mysql NDB Cluster 7.5.16 (And Later)
    Licensing Information User Manual MySQL NDB Cluster 7.5.16 (and later) Table of Contents Licensing Information .......................................................................................................................... 2 Licenses for Third-Party Components .................................................................................................. 3 ANTLR 3 .................................................................................................................................... 3 argparse .................................................................................................................................... 4 AWS SDK for C++ ..................................................................................................................... 5 Boost Library ............................................................................................................................ 10 Corosync .................................................................................................................................. 11 Cyrus SASL ............................................................................................................................. 11 dtoa.c ....................................................................................................................................... 12 Editline Library (libedit) ............................................................................................................. 12 Facebook Fast Checksum Patch ..............................................................................................
    [Show full text]
  • Safeguard for Privileged Passwords 6.0.9 LTS Release Notes
    Safeguard for Privileged Passwords 6.0.9 LTS Release Notes 03 March 2021, 06:20 These release notes provide information about the Safeguard for Privileged Passwords 6.0.9 LTS release. If you are updating a Safeguard for Privileged Passwords version prior to this release, read the release notes for the version found at: One Identity Safeguard for Privileged Passwords Technical Documentation. For the most recent documents and product information, see One Identity Safeguard for Privileged Passwords Technical Documentation. Release options Safeguard for Privileged Passwords includes two release versions: l Long Term Support (LTS) release, version 6.0.9 LTS l Feature release, version 6.9 The versions align with Safeguard for Privileged Sessions. For more information, see Long Term Support (LTS) and Feature Releases on page 13. About this release Safeguard for Privileged Passwords Version 6.0.9 LTS is a minor LTS release with resolved issues. For more details on the features and resolved issues, see: Safeguard for Privileged Passwords 6.0.9 LTS 1 Release Notes l Resolved issues NOTE: For a full list of key features in Safeguard for Privileged Passwords, see the Safeguard for Privileged Passwords Administration Guide. About the Safeguard product line The Safeguard for Privileged Passwords Appliance is built specifically for use only with the Safeguard for Privileged Passwords privileged management software, which is pre- installed and ready for immediate use. The appliance is hardened to ensure the system is secured at the hardware, operating system, and software levels. The hardened appliance approach protects the privileged management software from attacks while simplifying deployment and ongoing management and shortening the time frame to value.
    [Show full text]
  • Efficient Parallel I/O on Multi-Core Architectures
    Lecture series title/ lecture title Efficient parallel I/O on multi-core architectures Adrien Devresse CERN IT-SDC-ID Thematic CERN School of Computing 2014 1 Author(s) names – Affiliation Lecture series title/ lecture title How to make I/O bound application scale with multi-core ? What is an IO bound application ? → A server application → A job that accesses big number of files → An application that uses intensively network 2 Author(s) names – Affiliation Lecture series title/ lecture title Stupid example: Simple server monothreaded // create socket socket_desc = socket(AF_INET , SOCK_STREAM , 0); // bind the socket bind(socket_desc,(struct sockaddr *)&server , sizeof(server)); listen(socket_desc , 100); //accept connection from an incoming client while(1){ // declarations client_sock = accept(socket_desc, (struct sockaddr *)&client, &c); //Receive a message from client while( (read_size = recv(client_sock , client_message , 2000 , 0)) > 0{ // Wonderful, we have a client, do some useful work std::string msg("hello bob"); write(client_sock, msg.c_str(), msg.size()); } } 3 Author(s) names – Affiliation Lecture series title/ lecture title Stupid example: Let's make it parallel ! int main(int argc, char** argv){ // creat socket void do_work(int socket){ socket_desc = socket(AF_INET , SOCK_STREAM , 0); //Receive a message while( (read_size = // bind the socket recv(client_sock , bind(socket_desc, server , sizeof(server)); client_message , 2000 , 0)) > 0{ listen(socket_desc , 100); // Wonderful, we have a client // useful works //accept connection
    [Show full text]
  • Message Passing and Network Programming
    Message Passing and Network Programming Advanced Operating Systems Lecture 13 Colin Perkins | https://csperkins.org/ | Copyright © 2017 | This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Lecture Outline • Actors, sockets, and network protocols • Asynchronous I/O frameworks • Higher level abstractions Colin Perkins | https://csperkins.org/ | Copyright © 2017 2 Message Passing and Network Protocols • Recap: • Actor-based framework for message passing Send to • Each actor has a receive loop other actors Mailbox Actor Calls to one function per state Queue • Receive Message • Messages delivered by runtime system; Receiver processed sequentially Message Done Message Process • Actor can send messages in reply; Message Dispatcher return identity of next state Dequeue • Can we write network code this way? Request next • Send data by sending a message to an actor representing a socket • Receive messages representing data received on a socket Colin Perkins | https://csperkins.org/ | Copyright © 2017 3 Integrating Actors and Sockets Sending Thread Send to other actors Encoder Network Socket Mailbox Actor Queue Parser Receive Message Receiver Message Done Receiving Thread Message Process Message Dispatcher • Conceptually straightforward to integrate Dequeue actors with network code Request next • Runtime system maintains sending and
    [Show full text]
  • Copyright by Tongliang Liao 2017
    Copyright by Tongliang Liao 2017 The Thesis committee for Tongliang Liao certifies that this is the approved version of the following thesis: TAI: Threaded Asynchronous I/O Library for Performance and Portability APPROVED BY SUPERVISING COMMITTEE: Vijaychidambaram Velayudhan Pillai, Supervisor Simon Peter TAI: Threaded Asynchronous I/O Library for Performance and Portability by Tongliang Liao Thesis Presented to the Faculty of the Graduate School of the University of Texas at Austin in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science The University of Texas at Austin Dec 2017 TAI: Threaded Asynchronous I/O Library for Performance and Portability by Tongliang Liao, M.S.C.S The University of Texas at Austin, 2017 Supervisor: Vijaychidambaram Velayudhan Pillai In this paper, we investigate the behavior and performance of disk I/O using different types of libraries. We analyze the scenario where we can benefit from asyn- chronous I/O, and propose our cross-platform library design called TAI (Threaded Async I/O). TAI is designed to be a C++17 library with developer-friendly API. Our benchmark shows it can out-perform other libraries when asynchronous I/O is beneficial, and keep competitive speed in other cases. It also demonstrates TAI’s ability to retrieve 20% - 60% speedup on poorly scaled serial code by a simple library replacement. iv Table of Contents 1 Introduction 1 1.1 Related Work .................................................................................. 2 1.2 Background ..................................................................................... 2 1.2.1 POSIX Sync I/O ................................................................... 3 1.2.2 POSIX AIO .......................................................................... 3 1.2.3 C/C++ Standard I/O Functions............................................
    [Show full text]
  • A Sense of Time for Node.Js: Timeouts As a Cure for Event Handler Poisoning
    A Sense of Time for Node.js: Timeouts as a Cure for Event Handler Poisoning Anonymous Abstract—The software development community has begun to new Denial of Service attack that can be used against EDA- adopt the Event-Driven Architecture (EDA) to provide scalable based services. Our Event Handler Poisoning attack exploits web services. Though the Event-Driven Architecture can offer the most important limited resource in the EDA: the Event better scalability than the One Thread Per Client Architecture, Handlers themselves. its use exposes service providers to a Denial of Service attack that we call Event Handler Poisoning (EHP). The source of the EDA’s scalability is also its Achilles’ heel. Multiplexing unrelated work onto the same thread re- This work is the first to define EHP attacks. After examining EHP vulnerabilities in the popular Node.js EDA framework and duces overhead, but it also moves the burden of time sharing open-source npm modules, we explore various solutions to EHP- out of the thread library or operating system and into the safety. For a practical defense against EHP attacks, we propose application itself. Where OTPCA-based services can rely on Node.cure, which defends a large class of Node.js applications preemptive multitasking to ensure that resources are shared against all known EHP attacks by making timeouts a first-class fairly, using the EDA requires the service to enforce its own member of the JavaScript language and the Node.js framework. cooperative multitasking [89]. An EHP attack identifies a way to defeat the cooperative multitasking used by an EDA-based Our evaluation shows that Node.cure is effective, broadly applicable, and offers strong security guarantees.
    [Show full text]
  • Introduction to Asynchronous Programming
    Introduction to Asynchronous Programming In this document we introduce an asynchronous model for concurrent programming. For certain appli- cations, an asynchronous model may yield performance benefits over traditional multithreading. Much of the material presented in this document is taken from Dave Peticola’s excellent introduction to Twisted1, a Python framework for asynchronous programming. 1 The Models We will start by reviewing two (hopefully) familiar models in order to contrast them with the asynchronous model. By way of illustration we will imagine a program that consists of three conceptually distinct tasks which must be performed to complete the program. Note I am using task in the non-technical sense of something that needs to be done. The first model we will look at is the single-threaded synchronous model, in Figure 1 below: Figure 1: The single-threaded synchronous model This is the simplest style of programming. Each task is performed one at a time, with one finishing completely before another is started. And if the tasks are always performed in a definite order, the imple- mentation of a later task can assume that all earlier tasks have finished without errors, with all their output available for use — a definite simplification in logic. We can contrast the single-threaded synchronous model with the multi-threaded synchronous model illustrated in Figure 2. In this model, each task is performed in a separate thread of control. The threads are managed by the operating system and may, on a system with multiple processors or multiple cores, run truly concurrently, 1http://krondo.com/?page_id=1327 1 CS168 Async Programming Figure 2: The threaded model or may be interleaved together on a single processor.
    [Show full text]
  • Memc3: Compact and Concurrent Memcache with Dumber Caching and Smarter Hashing
    MemC3: Compact and Concurrent MemCache with Dumber Caching and Smarter Hashing Bin Fan, David G. Andersen, Michael Kaminsky∗ Carnegie Mellon University, ∗Intel Labs Abstract Standard Memcached, at its core, uses a typical hash table design, with linked-list-based chaining to handle This paper presents a set of architecturally and workload- collisions. Its cache replacement algorithm is strict LRU, inspired algorithmic and engineering improvements also based on linked lists. This design relies on locking to the popular Memcached system that substantially to ensure consistency among multiple threads, and leads improve both its memory efficiency and throughput. to poor scalability on multi-core CPUs [11]. These techniques—optimistic cuckoo hashing, a com- This paper presents MemC3 (Memcached with pact LRU-approximating eviction algorithm based upon CLOCK and Concurrent Cuckoo Hashing), a complete CLOCK, and comprehensive implementation of opti- redesign of the Memcached internals. This re-design mistic locking—enable the resulting system to use 30% is informed by and takes advantage of several observa- less memory for small key-value pairs, and serve up to tions. First, architectural features can hide memory access 3x as many queries per second over the network. We latencies and provide performance improvements. In par- have implemented these modifications in a system we ticular, our new hash table design exploits CPU cache call MemC3—Memcached with CLOCK and Concur- locality to minimize the number of memory fetches re- rent Cuckoo hashing—but believe that they also apply quired to complete any given operation; and it exploits more generally to many of today’s read-intensive, highly instruction-level and memory-level parallelism to overlap concurrent networked storage and caching systems.
    [Show full text]
  • A Study on Performance Improvement of Tor Network with Active Circuit Switching
    A Study on Performance Improvement of Tor Network with Active Circuit Switching Author Kale, Timothy Girry Doctoral Thesis in Engineering Graduate School of Information System Department of Information Network Systems The University of Electro-communications September 2015 A Study on Performance Improvement of Tor Network with Active Circuit Switching Author Kale, Timothy Girry Approved by supervisory committee: Chairperson: Assoc. Prof. Satoshi Ohzahata Member: Prof. Hiroyoshi Morita Member: Prof. Nagao Ogino Member: Assoc. Prof. Tomohiro Ogawa Member: Assoc. Prof. Shinobu Miwa © Copyright 2015 by Kale, Timothy Girry All Rights Reserved 動的経路切り替えを用いた Tor ネットワークの性 能改善に関する研究 カレ, ティモシー ギリ 概要 Tor ネットワークは分散サーキットスイッチによるアプリケーションレベルオーバ レイネットワークであり、世界中に配置されているオニオンルータによって、匿 名性のある通信を提供する。異なる転送速度を持つサーキットが TCP コネクショ ンに集約されてデータを転送するために競合が起き、Tor はネットワーク輻輳やパ フォーマンスに対して脆弱になっている。Tor では利用可能なネットワークの容量 の大部分はバルクのユーザのトラフィックによって消費されているため、対話性 のある軽量トラフィックの遅延が増大している。サーキットの不公平なトラフィ ックの分配によって、Tor ルータがボトルネックとなり、遅延が増加し、通信品質 も低下する。この問題のため、多くの Tor ユーザが Tor ネットワークを利用する 動機を低下させ、その結果、Tor ネットワークのパフォーマンスと匿名性が大幅に 低下している。 本論文では、まず、Tor ネットワークの遅延の問題を調査する。Tor サーキット のトラフィックと暗号科通信のための計算遅延の詳細の分析をするために測定分 析を行った。測定は研究室内に設置したテストベッドと実際の Tor ネットワーク で行い、遅延がどこで発生し、パケット損失がどのように遅延を引き起こすかを 分析した。Tor ネットワークで遅延増加の原因はサーキットの集約であることを明 らかにした。分析により、Tor ネットワークの設計は、低いネットワーク容量、大 きな遅延、TCP の送信バッファのキュー長の増大に対していくつか性能の問題が あることを明らかにした。 この性能低下の問題を解決するために、動的なサーキットスイッチ方式を用い て、限られたネットワーク容量の問題に対処する。トラフィックの輻輳の監視と より大きな帯域幅をもつ OR へのサーキットを動的に構築するのため、エントリ i OR に提案方式を実装した。提案方式では Tor の現在のアルゴリズムを修正し、バ ッファオーバーフローやソケット書き込み不可のイベントを考慮したメトリック
    [Show full text]
  • Event Handler Poisoning: Attacks and Defenses
    Event Handler Poisoning: Attacks and Defenses Anonymous Anonymous [email protected] Abstract—The software development community has begun to are the first to examine the security implications of using the adopt the Event-Driven Architecture (EDA) to provide scalable EDA at a software architecture-level. In xIII we describe a web services. Though the Event-Driven Architecture can offer new Denial of Service attack that can be used against EDA- better scalability than the One Thread Per Client Architecture, based services. Our Event Handler Poisoning attack identifies its use exposes service providers to a Denial of Service attack the most important limited resource in the EDA: the Event that we call Event Handler Poisoning (EHP). With the rise in the Handlers themselves. use of the EDA may come a plague of EHP attacks threatening critical Internet services. The EDA’s scalability is also its Achilles’ heel. Multiplex- In this work we define EHP attacks, dividing them into ing unrelated work onto the same thread reduces overhead, two types, CPU-bound and I/O-bound. After examining EHP but it also moves the burden of time sharing out of the thread vulnerabilities in the popular Node.js EDA framework and open- library or operating system and into the application itself. source npm modules, we explore two representative EHP attacks Where OTPCA-based services can rely on the preemptive in detail: Regular Expression Denial of Service (ReDoS) and I/O- multitasking promised by the underlying system to ensure based Denial of Service (IODoS). that resources are shared fairly, using the EDA requires the Using our Constant Worst-Case Execution Time (C-WCET) service to enforce its own cooperative multitasking [48].
    [Show full text]
  • VOLTTRON 3.0: User Guide
    PNNL-24907 Prepared for the U.S. Department of Energy under Contract DE-AC05-76RL01830 VOLTTRON 3.0: User Guide RG Lutes JN Haack S Katipamula KE Monson BA Akyol BJ Carpenter November 2015 DISCLAIMER United States Government. Neither the United States Government nor any agency thereof, nor Battelle Memorial Institute, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. PACIFIC NORTHWEST NATIONAL LABORATORY operated by BATTELLE for the UNITED STATES DEPARTMENT OF ENERGY under Contract DE-AC05-76RL01830 Printed in the United States of America Available to DOE and DOE contractors from the Office of Scientific and Technical Information, P.O. Box 62, Oak Ridge, TN 37831-0062; ph: (865) 576-8401, fax: (865) 576-5728 email: [email protected] Available to the public from the National Technical Information Service, U.S. Department of Commerce, 5285 Port Royal Rd., Springfield, VA 22161 ph: (800) 553-6847, fax: (703) 605-6900 email: [email protected] online ordering: http://www.ntis.gov/ordering.htm This document was printed on recycled paper.
    [Show full text]