DOCSLIB.ORG

Evaluating Websocket and Webrtc in the Context of a Mobile Internet of Things Gateway

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Evaluating Websocket and Webrtc in the Context of a Mobile Internet of Things Gateway Evaluating WebSocket and WebRTC in the Context of a Mobile Internet of Things Gateway GUNAY MERT KARADOGAN KTH Information and Communication Technology Degree project in Communication Systems Second level, 30.0 HEC Stockholm, Sweden Evaluating WebSocket and WebRTC in the Context of a Mobile Internet of Things Gateway Gunay Mert Karadogan Master of Science Thesis Embedded Systems School of Information and Communication Technology KTH Royal Institute of Technology Stockholm, Sweden 12 January 2013 Examiner: Professor Gerald Q. Maguire Jr. c Gunay Mert Karadogan, 12 January 2013 Abstract This thesis project explores two well-known real-time web technologies: WebSocket and WebRTC. It explores the use of a mobile phone as a gateway to connect wireless devices with short range of radio links to the Internet in order to foster an Internet of Things (IoT). This thesis project aims to solve the problem of how to collect real-time data from an IoT device, using the Earl toolkit. With this thesis project an Earl device is able to send real-time data to Internet connected devices and to other Earl devices via a mobile phone acting as a gateway. This thesis project facilitates the use of Earl in design projects for IoT devices. IoT enables communication with many different kinds of “things” such as cars, fridges, refrigerators, light bulbs, etc. The benefits of IoT range from financial savings due to saving energy to monitoring the heart activity of a patient with heart problems. There are many approaches to connect devices in order to create an IoT. One of these approaches is to use a mobile phone as a gateway, i.e., to act as a router, between IoT and the Internet. The WebSocket protocol provides efficient communication sessions between web servers and clients by reducing communication overhead. The WebRTC project aims to provide standards for real-time communications technology. WebRTC is important because it is the first real-time communications standard which is being built into browsers. This thesis evaluates the benefits which these two protocols offer when using a mobile phone as a gateway between an IoT and Internet. This thesis project implemented several test beds, collected data concerning the scalability of the protocols and the latency of traffic passing through the gateway, and presents a numerical analysis of the measurement results. Moreover, an LED module was built as a peripheral for an Earl device. The conclusion of the thesis is that WebSocket and WebRTC can be utilized to connect IoT devices to Internet. i Sammanfattning I detta examensarbete utforskas tva˚ valk¨ anda¨ realtidsteknologier pa˚ internet: WebSocket och WebRTC. Det utforskar anvandandet¨ av en mobiltelefon som gateway for¨ att ansluta tradl˚ osa¨ enheter - med kort rackvidd¨ - till Internet for¨ att skapa ett Internet of Things (IoT). Det har¨ examensarbetet fors¨ oker¨ med hjalp¨ av verktyget Earl losa¨ problemet med hur insamlandet av realtidsdata fran˚ en IoT-enhet skall genomforas.¨ I det har¨ examensprojektet kan en Earl-enhet skicka data i realtid till enheter med Internetanslutning, samt till andra Earl-enheter, med hjalp¨ av en mobiltelefon som gateway. Detta projektarbete forenklar¨ anvandandet¨ av Earl i design-projekt or¨ IoT-enheter. IoT tillater˚ kommunikation mellan olika sorters enheter, sa˚ som bilar, kyl- och frysskap,˚ glodlampor¨ etc. Fordelarna¨ med IoT kan vara allt fran˚ ekonomiska - tack vare minskad energiforbrukning¨ - till medicinska i form av overvakning¨ av puls hos patienter med hjartproblem.¨ Det finns manga˚ olika tillvagag¨ angss˚ att¨ for¨ att sammankoppla enheter till ett IoT. Ett av dessa ar¨ att anvanda¨ en mobiltelefon som en gateway, dvs en router mellan IoT och internet. WebSocket-protokollet erbjuder effektiv kommunikation mellan web-servrar och klienter tack vare minskad overfl¨ odig¨ dataoverf¨ oring.¨ WebRTC-projektet vill erbjuda standarder for¨ realtidskommunikation. WebRTC ar¨ viktigt da˚ det ar¨ den forsta¨ sadana˚ standarden som inkluderas i weblasare.¨ Det har¨ examensarbetet utvarderar¨ fordelarna¨ dessa tva˚ protokoll erbjuder i det fallet da˚ en mobiltelefon anvands¨ som gateway mellan ett IoT och Internet. I det har¨ examensprojektet implementerades ett flertal testmiljoer,¨ protokollens skalbarhet och fordr¨ ojningen¨ av trafiken genom mobiltelefonen (gateway) undersoktes.¨ Detta presenteras i en numerisk analys av matresultaten.¨ Dessutom byggdes en LED-modul som tillbehor¨ till en Earl-enhet. Slutsatsen av examensarbetet ar¨ att WebSocket och WebRTC kan anvandas¨ till att ansluta IoT-enheter till Internet. iii Acknowledgements I would like to acknowledge my gratitude to my examiner Professor Gerald Q. Maguire Jr. for his helpful comments and continuous suggestions during the development of this thesis. I thank my classmate Deniz Akkaya for letting me extend his thesis project by taking a different approach. Last but not the least, I would like to thank my family for supporting me throughout my life. v Contents 1 Introduction1 1.1 Problem Description........................2 1.2 Problem Context..........................4 1.3 Goal.................................5 1.4 Thesis Structure...........................6 1.5 Methodology............................6 2 WebSocket Experiments7 2.1 Background.............................8 2.1.1 Scaling WebSocket Connections.............. 10 2.2 Related Work............................ 12 2.3 Goal................................. 13 2.4 Tools and Experimental Setup................... 14 2.4.1 Command Line Tools.................... 14 2.4.1.1 SSH....................... 15 2.4.1.2 Sar........................ 15 2.4.1.3 kSar....................... 16 2.4.1.4 Git........................ 16 2.4.1.5 NTP....................... 17 2.4.1.6 Gnuplot..................... 17 2.4.2 Node.JS Server....................... 17 2.4.3 Amazon Web Services................... 23 2.4.3.1 Problems with Virtualization.......... 23 2.4.3.2 Setting Up Servers................ 24 2.4.4 Load Balancer: HAProxy................. 26 2.4.5 Redis Layer......................... 28 2.5 Data Collection........................... 29 2.5.1 Test Scripts......................... 29 2.5.1.1 load.js...................... 30 2.5.1.2 app.js....................... 31 2.5.2 Test Servers......................... 31 vii viii CONTENTS 2.5.3 Testing........................... 32 2.6 Data Analysis............................ 34 2.6.1 Throughput......................... 34 2.6.2 Message Service Time and Event Loop Lag........ 36 2.6.3 Response Time....................... 42 2.6.4 CPU Usage......................... 45 2.6.5 Commands processed by Redis.............. 48 2.6.6 Events in Client Instances................. 49 2.7 Conclusion............................. 50 3 WebRTC Experiments 51 3.1 Background............................. 51 3.1.1 WebRTC Protocols..................... 52 3.1.2 Possible Architectures for WebRTC............ 55 3.2 Related Work............................ 57 3.3 Goal................................. 58 3.4 WebRTC API............................ 59 3.4.1 RTCPeerConnection.................... 59 3.4.2 RTCSessionDescription.................. 60 3.4.3 RTCIceCandidate...................... 61 3.4.4 RTCDataChannel...................... 62 3.4.5 PeerJS............................ 63 3.4.5.1 PeerJS Client.................. 63 3.4.5.2 PeerServer.................... 64 3.5 Experimental Setup......................... 65 3.6 Data Collection........................... 66 3.7 Data Analysis............................ 68 3.7.1 Forwarding DataChannels over a Mobile Phone...... 68 3.7.1.1 One-way delay.................. 68 3.7.1.2 Throughput................... 71 3.7.2 Multiplexing and Demultiplexing DataChannels..... 74 3.7.2.1 Multiplexing................... 74 3.7.2.2 Demultiplexing................. 80 3.8 Conclusion............................. 85 4 LED Module for Earl 87 4.1 Background............................. 87 4.2 Goal................................. 88 4.3 Components............................. 88 4.4 Schematic.............................. 89 4.5 I2C Interface............................ 91 CONTENTS ix 4.6 Software............................... 93 4.7 Conclusion............................. 95 5 Conclusion 97 5.1 Conslusion............................. 97 5.2 Future Work............................. 98 5.3 Required Reflections........................ 99 Bibliography 101 A Network Kernel Configuration 113 B HAProxy Configuration 115 C Example of WebRTC DataChannel API 117 D Google’s STUN Servers 119 List of Figures 1.1 LED module, Earl, Phone and Internet...............5 2.1 Architecture for WebSocket Tests.................7 2.2 Polling versus Long Polling.....................8 2.3 WebSocket Traffic..........................9 2.4 Proxy Types............................. 11 2.5 Publishers and Subscribers..................... 14 2.6 Message Events for Case 1..................... 35 2.7 Message Events for Case 2..................... 35 2.8 Message Service Time For Case 1................. 37 2.9 Message Service Time For Case 2................. 37 2.10 Event Loop Lag for Case 1..................... 38 2.11 Event Loop Lag for Case 2..................... 38 2.12 Response Time for Case 1..................... 42 2.13 Response Time for Case 2..................... 43 2.14 CPU Usage of the Application Server for Case 1.......... 45 2.15 CPU Usage of the Application Servers for Case 2......... 46 2.16 CPU Usage of the Redis Server for Case 2............. 47 2.17 CPU Usage of the HAProxy Server for Case 2........... 47
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]
  • HTML5 Websocket Protocol and Its Application to Distributed Computing
    CRANFIELD UNIVERSITY Gabriel L. Muller HTML5 WebSocket protocol and its application to distributed computing SCHOOL OF ENGINEERING Computational Software Techniques in Engineering MSc arXiv:1409.3367v1 [cs.DC] 11 Sep 2014 Academic Year: 2013 - 2014 Supervisor: Mark Stillwell September 2014 CRANFIELD UNIVERSITY SCHOOL OF ENGINEERING Computational Software Techniques in Engineering MSc Academic Year: 2013 - 2014 Gabriel L. Muller HTML5 WebSocket protocol and its application to distributed computing Supervisor: Mark Stillwell September 2014 This thesis is submitted in partial fulfilment of the requirements for the degree of Master of Science © Cranfield University, 2014. All rights reserved. No part of this publication may be reproduced without the written permission of the copyright owner. Declaration of Authorship I, Gabriel L. Muller, declare that this thesis titled, HTML5 WebSocket protocol and its application to distributed computing and the work presented in it are my own. I confirm that: This work was done wholly or mainly while in candidature for a research degree at this University. Where any part of this thesis has previously been submitted for a degree or any other qualification at this University or any other institution, this has been clearly stated. Where I have consulted the published work of others, this is always clearly attributed. Where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work. I have acknowledged all main sources of help. Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed myself.
    [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]
  • Vidyo® Server for Webrtc Click to Collaborate
    Datasheet Vidyo® Server for WebRTC Click to Collaborate The Vidyo Server for WebRTC extends the Vidyo platform to include WebRTC capable browsers. Now join Vidyo conferences right from their web browser without any software installation. With a simple click-to-connect link, participants can enjoy up to HD video quality. The Vidyo Server for WebRTC is fully integrated with the Vidyo platform. This means participants joining through WebRTC can enjoy the interoperability delivered by the Vidyo platform including native Vidyo endpoints as well as third party H.323, SIP, and Microsoft® Skype for Business®. Deployed as a virtual machine, the Vidyo Server for WebRTC can be easily managed and scaled to meet demand. Concurrency is determined by flexible VidyoLine licenses that can float between native Vidyo endpoints and WebRTC clients as needed. Calls are secured through encryption using HTTPS, DTLS, and SRTP. Key Features Incredible User Experience Easy to Deploy & Manage • Native WebRTC support for plug-in free • Virtual server for easy deployment in your videoconferencing data center, colocation facility or in the cloud • Support for non-WebRTC browsers via • Dynamically scalable capacity based on VidyoWeb plug-in provisioned resources • Full two-way video communications on • Spin up new instances of Vidyo Server for ChromeBooks WebRTC to rapidly cluster and add capacity • Multipoint video layouts with up to 6 viewable • Simplify administration, configuration and participants maintenance with web-based interface • Click to connect ease of use • Secured media and signaling encryption • HD quality video and content • Automatic firewall and NAT traversal with ICE, • Share content with other participants* (Only TURN, and STUN support available on Chrome.
    [Show full text]
  • Kandy Link — Webrtc Gateway Using the Web to Extend the Value of Service Provider Networks
    Kandy Link — WebRTC Gateway Using the Web to Extend the Value of Service Provider Networks The Impact of WebRTC The adoption of the WebRTC standard by all of the major web browser providers creates an enormous opportunity to change the way people communicate. WebRTC makes it possible to engage in a two-way multi-media conversation (voice, video, screen share) without any extra software or purpose-built devices. Any modern device with a mic and speakers is now a full communications endpoint supporting voice, video and col- laboration tools. The simplicity of WebRTC-based communication access is in sharp contrast to traditional communication tools that require users to load a special app or a plugin for each website or ser- vice they use. This issue has gone from annoying to business impacting as many organizations have heightened security policies that preclude users from adding new applications. And since WebRTC leverages HTML5 and HTTPS, its firewall Multiple Deployment Options Kandy Link is deployed in a subscription based, fully managed friendly, meaning it works almost everywhere. model. Users can choose the operational deployment model Bridging the Digital Divide that best fits their use case: Ribbon’s Kandy Link Gateway offers service providers a simple Public Cloud – as a Service and scalable way to connect different generations of communi- No hardware or capital investment – WebRTC services are cation elements and customer experiences. delivered from the public Kandy cloud with access to Kandy’s entire apps portfolio. • Kandy Link can deliver line or station-side SIP services to existing communication elements (as a service, in network Private Cloud or on-premises) while delivering WebRTC-based services to In network or in a 3rd party data center.
    [Show full text]
  • Audiocodes Webrtc Solution DATA SHEET
    AudioCodes WebRTC Solution DATA SHEET Simplified Web Calling for Contact Centers and Service Providers The AudioCodes WebRTC solution is a quick and straightforward way for contact centers and service providers to supply intuitive and high-quality web calling functionality to their service centers. From implementing a simple click-to-call button on a consumer website or mobile app, right up to a fully featured agent client for voice and video calls, the AudioCodes WebRTC solution provides all the building blocks that you need to get web calling services up and running quickly and easily. Simple and scalable Powerful and robust Easy to install A single WebRTC device, either The WebRTC solution is fully integrated The Client SDK facilitates the quick virtual or hardware-based, in AudioCodes Mediant session border integration of the WebRTC solution seamlessly scalable from just a few controllers and inherits the SBCs’ into client websites or Android and sessions to several thousand strong security, high availability and iOS mobile apps transcoding capabilities Signaling AUDIOCODES Browser / Mobile WebRTC SDK WebRTC user Media Internet AudioCodes SBC Integrated WebRTC Gateway Carrier/Contact Center VoIP Network AudioCodes WebRTC Solution DATA SHEET Specifications WebRTC Gateway About AudioCodes AudioCodes Ltd. (NasdaqGS: AUDC) is a Deployment leading vendor of advanced voice networking VMWare KVM AWS Mediant 9000 Mediant 4000 method and media processing solutions for the digital workplace. With a commitment to the human 3,000 voice deeply embedded in its DNA, AudioCodes 5,000 WebRTC sessions 2,700 3,500 (20,000 on 1,000 enables enterprises and service providers (20K on roadmap) roadmap) to build and operate all-IP voice networks for unified communications, contact centers 3,000 1,050 integrated and hosted business services.
    [Show full text]
  • A Websocket-Based Approach to Transporting Web Application Data
    A WebSocket-based Approach to Transporting Web Application Data March 26, 2015 A thesis submitted to the Division of Graduate Studies and Research of the University of Cincinnati in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in the Department of Computer Science of the College of Engineering and Applied Science by Ross Andrew Hadden B.S., University of Cincinnati, Cincinnati, Ohio (2014) Thesis Adviser and Committee Chair: Dr. Paul Talaga Committee members: Dr. Fred Annexstein, Professor, and Dr. John Franco, Professor Abstract Most web applications serve dynamic data by either deferring an initial page response until the data has been retrieved, or by returning the initial response immediately and loading additional content through AJAX. We investigate another option, which is to return the initial response immediately and send additional content through a WebSocket connection as the data becomes available. We intend to illustrate the performance of this proposition, as compared to popular conventions of both a server- only and an AJAX approach for achieving the same outcome. This dissertation both explains and demonstrates the implementation of the proposed model, and discusses an analysis of the findings. We use a Node.js web application built with the Cornerstone web framework to serve both the content being tested and the endpoints used for data requests. An analysis of the results shows that in situations when minimal data is retrieved after a timeout, the WebSocket method is marginally faster than the server and AJAX methods, and when retrieving populated files or database records it is marginally slower. The WebSocket method considerably outperforms the AJAX method when making multiple requests in series, and when making requests in parallel the WebSocket and server approaches both outperform AJAX by a tremendous amount.
    [Show full text]
  • Nanostream Webrtc.Live
    nanoStream WebRTC.live Product Overview – Document V 1.4, 2017-01 © 2017 nanocosmos gmbh Setup secure online meetings at a distance or stream live events to thousands of worldwide viewers: nanoStream WebRTC.live makes it very easy to create custom ​ live video communication and interactive live streaming applications with low latency. In combination with the nanoStream H5Live Player, nanoStream ​ ​ WebRTC.live offers a seamless user experience for plugin-free live video broadcast on any device. What is nanoStream WebRTC.live? nanoStream WebRTC.live is a product platform developed by nanocosmos based on WebRTC and other streaming technologies like RTMP and H5Live. It is used in a variety of low-latency interactive live streaming use cases. WebRTC.live video chat combined with RTMP broadcasting ​ ​ ​ allows a unified communications strategy for companies - from 1-on-1 discussions with employees at a distance to sharing live events with 10.000 viewers. In addition to secure peer-to-peer communication, the WebRTC.live encoding platform can be used to broadcast live streams to large audiences. The live video broadcast can be integrated into ​ ​ any live streaming infrastructure with the unique WebRTC-RTMP server bridge, or in an end-to-end development with the nanoStream Cloud. What is WebRTC? WebRTC is a technology standard for audio/video-based real time communication. WebRTC video chats and broadcasts function directly within the web browser, with no additional plugin or app download required. The standard is supported by most browser vendors (Google Chrome, Firefox) and currently available plugin-free on all platforms (Windows, MacOS, Android), except Apple iOS.
    [Show full text]