DOCSLIB.ORG

User-Defined P2P Virtual Network Overlays for Ad-Hoc Collaboration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
User-Defined P2P Virtual Network Overlays for Ad-Hoc Collaboration EAI Endorsed Transactions on Collaborative Computing Research Article TinCan: User-Defined P2P Virtual Network Overlays for Ad-hoc Collaboration 1 1 1 2 1 Pierre St Juste∗ , Kyuho Jeong , Heungsik Eom , Corey Baker , Renato Figueiredo 1Advanced Computing and Information Systems Lab, 2Wireless and Mobile Systems Lab Electrical and Computer Engineering, University of Florida, Gainesville, FL, 32611, USA Abstract Virtual private networking (VPN) has become an increasingly important component of a collaboration environment because it ensures private, authenticated communication among participants, using existing collaboration tools, where users are distributed across multiple institutions and can be mobile. The majority of current VPN solutions are based on a centralized VPN model, where all IP traffic is tunneled through a VPN gateway. Nonetheless, there are several use case scenarios that require a model where end-to-end VPN links are tunneled upon existing Internet infrastructure in a peer-to-peer (P2P) fashion, removing the bottleneck of a centralized VPN gateway. We propose a novel virtual network — TinCan — based on peer- to-peer private network tunnels. It reuses existing standards and implementations of services for discovery notification (XMPP), reflection (STUN) and relaying (TURN), facilitating configuration. In this approach, trust relationships maintained by centralized (or federated) services are automatically mapped to TinCan links. In one use scenario, TinCan allows unstructured P2P overlays connecting trusted end-user devices — while only requiring VPN software on user devices and leveraging online social network (OSN) infrastructure already widely deployed. This paper describes the architecture and design of TinCan and presents an experimental evaluation of a prototype supporting Windows, Linux, and Android mobile devices. Results quantify the overhead introduced by the network virtualization layer, and the resource requirements imposed on services needed to bootstrap TinCan links. Received on 11 July 2014, accepted on 23 July 2014, published on 20 October 2014 Keywords: vpn, peer-to-peer, networking, privacy, virtual organization Copyright © 2014 Pierre St Juste et al., licensed to ICST. This is an open access article distributed under the terms of the Creative Commons Attribution licence (http://creativecommons.org/licenses/by/3.0/), which permits unlimited use, distribution and reproduction in any medium so long as the original work is properly cited. doi: 10.4108/ cc.1.2.e4 existing Internet infrastructure in a peer-to-peer (P2P) 1. Introduction fashion removing the bottleneck of a centralized VPN gateway, so called peer-to-peer virtual private networks Virtual private networking (VPN) has become an (P2PVPNs). increasingly important component of a collaboration The availability of P2PVPNs also help address the environment because it ensures private, authenticated growing privacy concerns caused by recent NSA reve- communication among participants, using existing lations through programs such as PRISM [1] because collaboration tools, where users are distributed across P2PVPNs create an environment where computing multiple institutions and can be mobile. VPNs also devices have end-to-end encrypted P2P tunnels which allow groups from different organizations to create are used to route IP packets without the involvement transient virtual networks thereby facilitating trusted of a middleman. This end-to-end encryption makes resource sharing across the public Internet. The digital monitoring more challenging because there is no majority of VPN solutions are based on a centralized overseer that has direct access to all IP traffic flowing VPN model, where all IP traffic is tunneled through a through the VPN, as is the case in most centralized VPN gateway. This model focuses primarily on one of VPN implementations. The main challenge to address these three goals: 1) secure network access to a private is architecting an open VPN technology that is efficient, corporate network, 2) circumvention of a firewall robust, easy to deploy and manage in a P2P fashion restricting complete access to the global Internet, or without compromising trust and while making it prac- 3) one-hop anonymity on the Internet. Nevertheless, tical for common use in today’s Internet. there are several use case scenarios that require a This paper presents TinCan, a P2PVPN that allows model where end-to-end VPN links are tunneled upon flexible V PN o verlays o f d ifferent t opologies t hat can be instantiated atop Internet infrastructure with low ∗Corresponding author. Email: [email protected]fl.edu European Alliance EAI Endorsed Transactions on 1 Collaborative Computing EAI for Innovation 06 -10 2014 | Volume 01 | Issue 2 | e4 P. St Juste et al. configuration and management overhead 1. TinCan control of TinCan link creation and deletion, mapping integrates with existing online social networking IP addresses to identities and TinCan links, and (OSN) services for peer discovery and notification configuring virtual networking interface. Coordination to allow deployments that bootstrap private peer-to- among endpoints and overlay routing is possible peer tunnels using relationships established through through message forwarding along TinCan virtual IPv6 intuitive OSN interfaces. The overlay implied by links, supporting user-defined overlay topologies and private end-to-end TinCan links exposes IP endpoints, routing policies implemented as a separate module allowing existing applications to work unmodified, and from the core datapath. providing a basis for overlay peer-to-peer routing in the virtual network. The TinCan design also supports To demonstrate its applicability in different use cases, tunneling of both IPv4 and IPv6 packets within TinCan implements a common datapath based on the VPN, which is implemented as IPv6 packets Google’s libjingle P2P library [6], and two different Tin- encapsulated within UDP packets and sent over IPv4 Can controllers: a “group” controller (which provides a P2P tunnels, as well as IPv4 packets within IPv6 UDP private subnet with a flat address space for group col- packets. laboration), and a “social” controller (which automati- A key goal in the design is to minimize the amount cally creates VPN links from social networking relation- of configuration and infrastructure necessary to sustain ships established through an external OSN provider, these virtual private networks. Because TinCan runs on for user-to-user collaboration). With the GroupVPN endpoints (e.g. VMs or personal devices), it requires controller, nodes bind to the same subnet in the vir- little additional infrastructure for maintaining the tual network and can address each other using unique network. TinCan links make it possible for VMs private IP addresses within the scope of the VPN. In SocialVPN mode, each user is able to define their own and mobile devices to tunnel IP traffic directly to each other — even when constrained by NATs — private IP range/subnet and locally map social peers while simultaneously giving end users the flexibility to IP addresses within that subnet thus forming an to define the IP address ranges, subnets, and access unstructured social network graph overlay topology. control policies for their private network. TinCan The analysis shows that the TinCan design is practical integrates with ubiquitous messaging overlays that use and scalable. In the experiments, a network of 300 the XMPP protocol for signaling, along with well- nodes consumes 29 KB/s of bandwidth on the XMPP adopted technologies for NAT traversal (STUN, TURN, server. The management of these TinCan links uses and ICE [2–4]) to bootstrap encrypted TinCan links. In about 1 KB/s of bandwidth per connection. The one use case, social peers can run TinCan to deploy design incurs a 14% network per-packet encapsulation VPNs comprised of their personal devices (including overhead. This overhead is due to our use of an mobile) and their social peers’ devices by leveraging MTU of 1280 bytes — selected to minimize packet existing Internet services for discovery and reflection fragmentation — rather than the traditional 1500 (e.g. Google Hangouts, Jabber.org XMPP and STUN byte MTU along with the cost of an additional 40- servers). The only requirement for deploying a TinCan byte header necessary to encapsulate the virtual IP VPN is an XMPP server; therefore, end users can use packets. To measure system throughput, we conducted any freely available XMPP service on the Internet, an experiment between two nodes in a 1 Gbps LAN or deploy their own private XMPP server such as and ran the iperf networking benchmark to obtain the ejabberd [5]. bandwidth measurements. The results show a latency The novel design of TinCan is logically divided in of less than 1 ms and a TCP bandwidth of 64 Mbps; two key layers — reminiscent of the OpenFlow model, since our target is to create virtual networks across the but applied to tunnels over UDP/TCP links: 1) a Internet, for most applications, the bottleneck will be datapath packet capture/forwarding layer, responsible the bandwidth limit imposed by their local ISPs. for capturing/injecting packets from a virtual NIC, and maintaining TinCan links (over UDP or TCP) to The main contribution of this paper is a novel neighboring peers, and 2) a control layer, responsible VPN design that leverages XMPP servers to bootstrap for implementing policies for the creation and tear- end-to-end VPN tunnels, supports decoupled con- down of TinCan links. Each TinCan peer runs the two troller/datapath
Load more

Recommended publications
  • Uila Supported Apps
    Uila Supported Applications and Protocols updated Oct 2020 Application/Protocol Name Full Description 01net.com 01net website, a French high-tech news site. 050 plus is a Japanese embedded smartphone application dedicated to 050 plus audio-conferencing. 0zz0.com 0zz0 is an online solution to store, send and share files 10050.net China Railcom group web portal. This protocol plug-in classifies the http traffic to the host 10086.cn. It also 10086.cn classifies the ssl traffic to the Common Name 10086.cn. 104.com Web site dedicated to job research. 1111.com.tw Website dedicated to job research in Taiwan. 114la.com Chinese web portal operated by YLMF Computer Technology Co. Chinese cloud storing system of the 115 website. It is operated by YLMF 115.com Computer Technology Co. 118114.cn Chinese booking and reservation portal. 11st.co.kr Korean shopping website 11st. It is operated by SK Planet Co. 1337x.org Bittorrent tracker search engine 139mail 139mail is a chinese webmail powered by China Mobile. 15min.lt Lithuanian news portal Chinese web portal 163. It is operated by NetEase, a company which 163.com pioneered the development of Internet in China. 17173.com Website distributing Chinese games. 17u.com Chinese online travel booking website. 20 minutes is a free, daily newspaper available in France, Spain and 20minutes Switzerland. This plugin classifies websites. 24h.com.vn Vietnamese news portal 24ora.com Aruban news portal 24sata.hr Croatian news portal 24SevenOffice 24SevenOffice is a web-based Enterprise resource planning (ERP) systems. 24ur.com Slovenian news portal 2ch.net Japanese adult videos web site 2Shared 2shared is an online space for sharing and storage.
    [Show full text]
  • Enabling TPM Based System Security Features
    Enabling TPM based system security features Andreas Fuchs <[email protected]> Who am I ? ● 13 year on/off TPMs ● Fraunhofer SIT: Trustworthy Platforms ● TCG-member: TPM Software Stack WG ● Maintainer – tpm2-tss: The libraries – tpm2-tss-engine: The openssl engine – tpm2-totp: Computer-to-user attestation (mjg’s tpm-totp reimplemented for 2.0) 2 The hardware stack ● Trusted Platform Module (TPM) 2.0 – Smartcard-like capabilities but soldered in – Remote Attestation capabilities – As separate chip (LPC, SPI, I²C) – In Southbridge / Firmware – Via TEEs/TrustZone, etc – Thanks to Windows-Logos in every PC ● CPU – OS, TSS 2.0, where the fun is... 3 The TPM Software Stack 2.0 ● Kernel exposes /dev/tpm0 with byte buffers ● tpm2-tss is like the mesa of TCG specs ● TCG specifications: – TPM spec for functionality – TSS spec for software API ● tpm2-tss implements the glue ● Then comes core module / application integration – Think GDK, but OpenSSL – Think godot, but pkcs11 – Think wayland, but cryptsetup 4 The TSS APIs System API (sys) Enhanced SYS (esys) Feature API (FAPI) • 1:1 to TPM2 cmds • Automate crypto for • Spec in draft form HMAC / encrypted • TBimplemented • Cmd / Rsp sessions • No custom typedefs U serialization • Dynamic TCTI • JSON interfaces s • No file I/O loading • Provides Policy e • No crypto • Memory allocations language r • No heap / malloc • No file I/O • Provides keystore S p TPM Command Transmission Interface (tss2-tcti) p a Abstract command / response mechanism, • No crypto, heap, file I/O a Decouple APIs
    [Show full text]
  • Master Thesis
    Master's Programme in Computer Network Engineering, 60 credits MASTER Connect street light control devices in a secure network THESIS Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Network security, 15 credits Halmstad 2015-02-16 “Connect street light control devices in a secure network” Master’s Thesis in Computer Network engineering 2014 Authors: Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Supervisor: Alexey Vinel Examiner: Tony Larsson Preface This thesis is submitted in partial fulfilment of the requirements for a Master’s Degree in Computer Network Engineering at the Department of Information Science - Computer and Electrical Engineering, at University of Halmstad, Sweden. The research - implementation described herein was conducted under the supervision of Professor Alexey Vinel and in cooperation with Greinon engineering. This was a challenging trip with both ups and downs but accompanied by an extend team of experts, always willing to coach, sponsor, help and motivate us. For this we would like to thank them. We would like to thank our parents and family for their financial and motivational support, although distance between us was more than 1500 kilometres. Last but not least we would like to thank our fellow researchers and friends on our department for useful discussions, comments, suggestions, thoughts and also creative and fun moments we spend together. i Abstract Wireless communications is a constantly progressing technology in network engineering society, creating an environment full of opportunities that are targeting in financial growth, quality of life and humans prosperity. Wireless security is the science that has as a goal to provide safe data communication between authorized users and prevent unauthorized users from gaining access, deny access, damage or counterfeit data in a wireless environment.
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • Distributed Deep Learning in Open Collaborations
    Distributed Deep Learning In Open Collaborations Michael Diskin∗y~ Alexey Bukhtiyarov∗| Max Ryabinin∗y~ Lucile Saulnierz Quentin Lhoestz Anton Sinitsiny~ Dmitry Popovy~ Dmitry Pyrkin~ Maxim Kashirin~ Alexander Borzunovy~ Albert Villanova del Moralz Denis Mazur| Ilia Kobelevy| Yacine Jernitez Thomas Wolfz Gennady Pekhimenko♦♠ y Yandex, Russia z Hugging Face, USA ~ HSE University, Russia | Moscow Institute of Physics and Technology, Russia } University of Toronto, Canada ♠ Vector Institute, Canada Abstract Modern deep learning applications require increasingly more compute to train state-of-the-art models. To address this demand, large corporations and institutions use dedicated High-Performance Computing clusters, whose construction and maintenance are both environmentally costly and well beyond the budget of most organizations. As a result, some research directions become the exclusive domain of a few large industrial and even fewer academic actors. To alleviate this disparity, smaller groups may pool their computational resources and run collaborative experiments that benefit all participants. This paradigm, known as grid- or volunteer computing, has seen successful applications in numerous scientific areas. However, using this approach for machine learning is difficult due to high latency, asymmetric bandwidth, and several challenges unique to volunteer computing. In this work, we carefully analyze these constraints and propose a novel algorithmic framework designed specifically for collaborative training. We demonstrate the effectiveness of our approach for SwAV and ALBERT pretraining in realistic conditions and achieve performance comparable to traditional setups at a fraction of the cost. arXiv:2106.10207v1 [cs.LG] 18 Jun 2021 Finally, we provide a detailed report of successful collaborative language model pretraining with 40 participants. 1 Introduction The deep learning community is becoming increasingly more reliant on transfer learning.
    [Show full text]
  • NAT Traversal About
    NAT Traversal About Some difficulties have been encountered with devices that have poor NAT support. FreeSWITCH goes to great lengths to repair broken NAT support in phones and gateway devices. In order to aid FreeSWITCH in traversing NAT please see the External profile page. Some routers offer an Application Layer Gateway feature which can prevent FreeSWITCH NAT traversal from working. See the ALG page for more information, including how to disable it. Using STUN to aid in NAT Traversal STUN is a method to allow an end host (i.e. phone) to discover its public IP address if it is located behind a NAT . Using this method requires a STUN server on the public internet and a client on the phone. The phone's STUN client queries the STUN server for it's own public IP and transmits the information it has received in it's connection information in the SIP packets it sends to the SIP server. Enable and configure STUN settings on your phone in order correctly to report your phone's contact information to FreeSWITCH when registering. Unfortunately, not all phones have a properly working STUN client. STUN servers This site contains a list of public STUN servers: https://gist.github.com/zziuni/3741933 stun.freeswitch.org is never guaranteed to be up and running so use it in production at your own risk. There are several open source projects to run your own STUN server, e.g. STUNTMAN Using FreeSWITCH built-in methods to aid in NAT Traversal nat-options-ping This parameter causes FreeSWITCH to regularly (every 20 - 40s) send an OPTIONS packet to NATed registered endpoints in order to keep the port on the clients firewall open.
    [Show full text]
  • NAT and NAT Traversal Lecturer: Andreas Müller [email protected]
    NAT and NAT Traversal lecturer: Andreas Müller [email protected] NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 39 NAT: Network Address Translation Problem: shortage of IPv4 addresses . more and more devices . only 32bit address field Idea: local network uses just one IP address as far as outside world is concerned: . range of addresses not needed from ISP: just one IP address for all devices . can change addresses of devices in local network without notifying outside world . can change ISP without changing addresses of devices in local network . devices inside local net not explicitly addressable, visible by outside world (a security plus). NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 40 NAT: Network Address (and Port) Translation rest of local network Internet (e.g., home network) 10.0.0/24 10.0.0.1 10.0.0.4 10.0.0.2 138.76.29.7 10.0.0.3 All datagrams leaving local Datagrams with source or network have same single source destination in this network NAT IP address: 138.76.29.7, have 10.0.0/24 address for different source port numbers source, destination (as usual) NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 41 NAT: Network Address Translation Implementation: NAT router must: . outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #) . remote clients/servers will respond using (NAT IP address, new port #) as destination addr. remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair -> we have to maintain a state in the NAT .
    [Show full text]
  • Peer-To-Peer Protocol and Application Detection Support
    Peer-to-Peer Protocol and Application Detection Support This appendix lists all the protocols and applications currently supported by Cisco ASR 5500 ADC. • Supported Protocols and Applications, page 1 Supported Protocols and Applications This section lists all the supported P2P protocols, sub-protocols, and the applications using these protocols. Important Please note that various client versions are supported for the protocols. The client versions listed in the table below are the latest supported version(s). Important Please note that the release version in the Supported from Release column has changed for protocols/applications that are new since the ADC plugin release in August 2015. This will now be the ADC Plugin Build number in the x.xxx.xxx format. The previous releases were versioned as 1.1 (ADC plugin release for December 2012 ), 1.2 (ADC plugin release for April 2013), and so on for consecutive releases. New in this Release This section lists the supported P2P protocols, sub-protocols and applications introduced in the ADC Plugin release for December 1, 2017. ADC Administration Guide, StarOS Release 21.6 1 Peer-to-Peer Protocol and Application Detection Support New in this Release Protocol / Client Client Version Group Classification Supported from Application Release 6play 6play (Android) 4.4.1 Streaming Streaming-video ADC Plugin 2.19.895 Unclassified 6play (iOS) 4.4.1 6play — (Windows) BFM TV BFM TV 3.0.9 Streaming Streaming-video ADC Plugin 2.19.895 (Android) Unclassified BFM TV (iOS) 5.0.7 BFM — TV(Windows) Clash Royale
    [Show full text]
  • Developing P2P Protocols Across NAT Girish Venkatachalam
    Developing P2P Protocols across NAT Girish Venkatachalam Abstract Hole punching is a possible solution to solving the NAT problem for P2P protocols. Network address translators (NATs) are something every software engineer has heard of, not to mention networking professionals. NAT has become as ubiquitous as the Cisco router in networking terms. Fundamentally, a NAT device allows multiple machines to communicate with the Internet using a single globally unique IP address, effectively solving the scarce IPv4 address space problem. Though not a long-term solution, as originally envisaged in 1994, for better or worse, NAT technology is here to stay, even when IPv6 addresses become common. This is partly because IPv6 has to coexist with IPv4, and one of the ways to achieve that is by using NAT technology. This article is not so much a description of how a NAT works. There already is an excellent article on this subject by Geoff Huston (see the on-line Resources). It is quite comprehensive, though plenty of other resources are available on the Internet as well. This article discusses a possible solution to solving the NAT problem for P2P protocols. What Is Wrong with NAT? NAT breaks the Internet more than it makes it. I may sound harsh here, but ask any peer-to-peer application developer, especially the VoIP folks, and they will tell you why. For instance, you never can do Web hosting behind a NAT device. At least, not without sufficient tweaking. Not only that, you cannot run any service such as FTP or rsync or any public service through a NAT device.
    [Show full text]
  • On the Design and Implementation of IP-Over-P2P Overlay Virtual Private
    DOI:10.1587/transcom.2019CPI0001 Publicized:2019/08/05 This article has been accepted and published on J-STAGE in advance of copyediting. Content is final as presented. 1 Invited Paper On the Design and Implementation of IP-over-P2P Overlay Virtual Private Networks Kensworth Subratie†, Saumitra Aditya†, Vahid Daneshmand†, Kohei Ichikawa††, and Renato Figueiredo† SUMMARY The success and scale of the Internet and its protocol IP has protocols (e.g. TLS [2], [3]). As a result, distributed spurred emergent distributed technologies such as fog/edge computing and applications that run across the Internet often must deal with new application models based on distributed containerized microservices. The Internet of Things and Connected Communities are poised to build on devices without public IPv4 addresses that are behind these technologies and models and to benefit from the ability to various NAT and firewall middleboxes and must create communicate in a peer-to-peer (P2P) fashion. Ubiquitous sensing, actuating secure transport sessions for communication. While these and computing implies a scale that breaks the centralized cloud computing issues are relatively easy to handle with client-server model. Challenges stemming from limited IPv4 public addresses, the need applications, they place a burden to applications where peer- for transport layer authentication, confidentiality and integrity become a burden on developing new middleware and applications designed for the to-peer communication is needed. network’s edge. One approach - not reliant on the slow adoption of IPv6 - Emerging distributed applications in edge/fog [4], [5] is the use of virtualized overlay networks, which abstract the complexities computing are poised to benefit from the ability for IoT and of the underlying heterogeneous networks that span the components of edge nodes to communicate in a peer-to-peer fashion.
    [Show full text]
  • Internet Telephony PBX System IPX-2200/IPX-2500
    Internet Telephony PBX System IPX-2200/IPX-2500 Internet Telephony PBX System IPX-2200 IPX-2500 1 Internet Telephony PBX System IPX-2200/IPX-2500 Copyright Copyright (C) 2016 PLANET Technology Corp. All rights reserved. The products and programs described in this User’s Manual are licensed products of PLANET Technology. This User’s Manual contains proprietary information protected by copyright, and this User’s Manual and all accompanying hardware, software, and documentation are copyrighted. No part of this User’s Manual may be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form by any means by electronic or mechanical including photocopying, recording, or information storage and retrieval systems, for any purpose other than the purchaser's personal use, and without the prior written permission of PLANET Technology. Disclaimer PLANET Technology does not warrant that the hardware will work properly in all environments and applications, and makes no warranty and representation, either implied or expressed, with respect to the quality, performance, merchantability, or fitness for a particular purpose. PLANET has made every effort to ensure that this User’s Manual is accurate; PLANET disclaims liability for any inaccuracies or omissions that may have occurred. Information in this User’s Manual is subject to change without notice and does not represent a commitment on the part of PLANET. PLANET assumes no responsibility for any inaccuracies that may be contained in this User’s Manual. PLANET makes no commitment to update or keep current the information in this User’s Manual, and reserves the right to make improvements to this User’s Manual and/or to the products described in this User’s Manual, at any time without notice.
    [Show full text]
  • Technology Stack for Decentralized Mobile Services
    Technology Stack for Decentralized Mobile Services Matouš Skála Technology Stack for Decentralized Mobile Services by Matouš Skála to obtain the degree of Master of Science at the Delft University of Technology, to be defended publicly on Monday August 31, 2020 at 3:00 PM. Student number: 4893964 Project duration: November 15, 2019 – August 31, 2020 Thesis committee: Dr.ir. J.A. Pouwelse, TU Delft, supervisor Dr. J.S. Rellermeyer, TU Delft Dr. N. Yorke-Smith, TU Delft An electronic version of this thesis is available at http://repository.tudelft.nl/. Preface When I was choosing my thesis topic, I originally came up with an idea of designing a decen- tralized social network. After realizing how ambitious that goal was, I later decided to focus on more fundamental issues first and create a library that would allow for building any de- centralized applications, running purely on an overlay network consisting of smartphones. Rather than reinventing the wheel, I took inspiration from an existing networking library de- veloped at TU Delft over the last decade and created its wire-compatible implementation in Kotlin. Interestingly, in the end, I have even implemented a trivial social network to demon- strate the usage of the library, returning back to the original idea. I would like to thank my supervisor Johan Pouwelse for an endless stream of fresh ideas and valuable feedback, and to PhD students of the Delft Blockchain Lab for numerous coffee meetings and for serving me as a walking documentation of the existing codebase. Matouš Skála Prague,
    [Show full text]