DOCSLIB.ORG

Concurrent Programming for Scalable Web Architectures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Concurrent Programming for Scalable Web Architectures Concurrent Programming for Scalable Web Architectures Diploma Thesis VS-D01-2012 Institute of Distributed Systems Faculty of Engineering and Computer Science Ulm University Benjamin Erb April óþ, óþÕó is thesis has been written by Benjamin Erb in óþÕÕ/óþÕó as a requirement for the completion of the diploma course Media Informatics at Ulm University. It has been submitted on April óþ, óþÕó. Benjamin Erb Mail: [email protected] WWW: http://www.benjamin-erb.de Institute of Distributed Systems Faculty of Engineering and Computer Science, Ulm University James-Franck-Ring ÉþÕ Ulm, Germany is work is licensed under a Creative Commons Attribution-ShareAlike ì.þ Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, ÕßÕ Second Street, Suite ìþþ, San Francisco, California, ɦÕþ¢, USA. Title Image Bustling Beijing by Trey Ratcli, released under CC-BY-NC-SA ó.þ license. http://www.flickr.com/photos/stuckincustoms/5069047950/ http://creativecommons.org/licenses/by-nc-sa/2.0/ Icon Sets Iconic (http://somerandomdude.com/work/iconic/) by P.J. Onori, released under CC-BY-SA ì.þ license. http://creativecommons.org/licenses/by-sa/3.0/) Picol (http://picol.org) by Melih Bilgil, released under released under CC-BY-SA ì.þ license. http://creativecommons.org/licenses/by-sa/3.0/ Abstract Web architectures are an important asset for various large-scale web applications, such as social networks or e-commerce sites. Being able to handle huge numbers of users concurrently is essential, thus scalability is one of the most important features of these architectures. Multi- core processors, highly distributed backend architectures and new web technologies force us to reconsider approaches for concurrent programming in order to implement web applications and full scalability demands. While focusing on dierent stages of scalable web architectures, we provide a survey of competing concurrency approaches and point to their adequate usages. iii Preface About this Work My name is Benjamin Erb and I have been studying Media Informatics at Ulm University since óþþä. is work represents a major requirement for the completion of my diploma course in óþÕó. For a long time, I have been taking a great interest in web technologies, scalable architectures, distributed systems and programming concurrency. As a consequence, the topic of my thesis covers most of these interests. In fact, it considers the overlap of these subjects when it comes to the design, implementation and programming of scalable web architectures. I hope to provide a comprehensive introduction to this topic, which I have missed so far. As such a primer might also be interesting for many others, I am happy to release my thesis under a free license to the general public. is thesis incorporates both academic research papers and practically orientated publications and resources. In essence, I aimed for a survey of dierent approaches from a conceptual and theoretical perspective. Hence, a quantitative benchmarking of concrete technologies was out of scope for my work. Also, the extents of the subjects brought up only allowed for a brief overview. e bibliography and the referenced resources provide a good starting point for further readings. I am very interested in your feedback, your thoughts on the topic and your ideas! Feel free to contact me (http://www.benjamin-erb.de) or get in touch with me via Twitter: @b_erb v vi Acknowledgements First of all, I would like to thank my advisor Jörg Domaschka for his steady and precious support. He gave me substantial liberties, but was always available for a lot of good advices and formative chit-chats when I needed them. I also thank my supervisors, Prof. Dr. Hauck and Prof. Dr. Weber, especially for allowing me to work on such a conceptual and comprehensive topic for my thesis. Aer all, both of them need to be held responsible for my interests in these topics to some degree. I want to thank all of my proofreaders—namely and alphabetically— Christian Koch, Katja Rogers, Linda Ummenhofer, Lisa Adams, Matthias Matousek, Michael Müller, Nicolai Waniek and Timo Müller. I also want to thank Jan Lehnardt and Lena Herrmann who reinforced my decision to release this thesis. Finally, I want to say to everyone, who—directly or indirectly—helped me and supported me during the time I wrote this thesis: ank you! A labyrinth of symbols...An invisible labyrinth of time. — Jorge Luis Borges, e Garden of Forking Paths Contents 1 Introduction1 1.1 Motivation ........................................ 1 1.2 Scope of this Thesis ................................... 3 1.3 Methodology of the Study ............................... 3 1.4 Road Map ......................................... 4 2 The World Wide Web, Concurrency and Scalability5 2.1 The World Wide Web .................................. 5 2.1.1 Uniform Resource Identifiers ........................ 5 2.1.2 The Hypertext Transfer Protocol ...................... 6 2.1.3 Web Formats .................................. 9 2.2 Web Applications .................................... 10 2.2.1 Web Sites .................................... 10 2.2.2 Web Services .................................. 11 2.3 Concurrency ....................................... 14 2.3.1 Concurrency and Parallelism ........................ 14 2.3.2 Models for Programming Concurrency .................. 16 2.3.3 Synchronization and Coordination as Concurrency Control ...... 17 2.3.4 Tasks, Processes and Threads ........................ 18 2.3.5 Concurrency, Programming Languages and Distributed Systems .. 19 2.4 Scalability ......................................... 19 2.4.1 Horizontal and Vertical Scalability ..................... 20 2.4.2 Scalability and other Non-functional Requirements ........... 20 2.4.3 Scalability and Concurrency ......................... 21 2.4.4 Scalability of Web Applications and Architectures ............ 22 2.5 Summary ......................................... 22 3 The Quest for Scalable Web Architectures 23 3.1 Traditional Web Architectures ............................ 23 3.1.1 Server-Side Technologies for Dynamic Web Content .......... 23 3.1.2 Tiered Architectures .............................. 25 ix x Contents 3.1.3 Load-Balancing ................................ 26 3.2 Cloud Architectures ................................... 29 3.2.1 Cloud Computing ............................... 29 3.2.2 PaaS and IaaS Providers ........................... 30 3.3 An Architectural Model for Scalabale Web Infrastructures ............ 32 3.3.1 Design Guidelines and Requirements ................... 32 3.3.2 Components .................................. 34 3.3.3 Critical Reflection of the Model ....................... 41 3.4 Scaling Web Applications ............................... 41 3.4.1 Optimizing Communication and Content Delivery ........... 41 3.4.2 Speeding up Web Site Performance .................... 42 3.5 Summary ......................................... 43 4 Web Server Architectures for High Concurrency 45 4.1 Overview ......................................... 45 4.1.1 Request Handling Workflow ......................... 46 4.1.2 The C10K Problem ............................... 47 4.1.3 I/O Operation Models ............................. 47 4.2 Server Architectures .................................. 49 4.2.1 Thread-based Server Architectures ..................... 49 4.2.2 Event-driven Server Architectures ..................... 52 4.2.3 Combined Approaches ............................ 56 4.2.4 Evaluation .................................... 58 4.3 The Case of Threads vs. Events ............................ 59 4.3.1 The Duality Argument ............................ 59 4.3.2 A Case for Threads ............................... 61 4.3.3 A Case for Events ............................... 62 4.3.4 A Conflation of Distinct Concepts ...................... 63 4.3.5 Conclusion ................................... 65 4.4 Summary ......................................... 66 5 Concurrency Concepts for Applications and Business Logic 69 5.1 Overview ......................................... 69 5.2 Concurrency Based on Threads, Locks and Shared State ............. 72 5.2.1 The Implications of Shared and Mutable State .............. 72 5.2.2 Case Study: Concurrency in Java ...................... 74 5.2.3 Multithreading and Locks for Concurrent Application Logic ...... 76 5.3 Concurrency via Software Transactional Memory ................. 78 5.3.1 Transactional Memory ............................ 78 5.3.2 Software Transactional Memory ...................... 79 Contents xi 5.3.3 The Transactional Memory / Garbage Collection Analogy ....... 80 5.3.4 Case Study: Concurrency in Clojure ..................... 81 5.3.5 STM for Concurrent Application Logic ................... 84 5.4 Actor-based Concurrency ............................... 84 5.4.1 The Actor Model ................................ 84 5.4.2 Actor Implementations for Concurrent Programming ......... 85 5.4.3 Programming with Actors .......................... 87 5.4.4 Case Study: Concurrency in Scala ...................... 88 5.4.5 Actors for Concurrent Application Logic .................. 89 5.5 Event-driven Concurrency ............................... 90 5.5.1 Event-driven Architectures .......................... 91 5.5.2 Single-threaded Event-driven Frameworks ................ 91 5.5.3 Case Study: Concurrency in node.js .................... 93 5.5.4 Event-driven Concurrent Application Logic ................ 94 5.6 Other Approaches
Load more

Recommended publications
  • Akka Java Documentation Release 2.2.5
    Akka Java Documentation Release 2.2.5 Typesafe Inc February 19, 2015 CONTENTS 1 Introduction 1 1.1 What is Akka?............................................1 1.2 Why Akka?..............................................3 1.3 Getting Started............................................3 1.4 The Obligatory Hello World.....................................7 1.5 Use-case and Deployment Scenarios.................................8 1.6 Examples of use-cases for Akka...................................9 2 General 10 2.1 Terminology, Concepts........................................ 10 2.2 Actor Systems............................................ 12 2.3 What is an Actor?.......................................... 14 2.4 Supervision and Monitoring..................................... 16 2.5 Actor References, Paths and Addresses............................... 19 2.6 Location Transparency........................................ 25 2.7 Akka and the Java Memory Model.................................. 26 2.8 Message Delivery Guarantees.................................... 28 2.9 Configuration............................................. 33 3 Actors 65 3.1 Actors................................................ 65 3.2 Typed Actors............................................. 84 3.3 Fault Tolerance............................................ 88 3.4 Dispatchers.............................................. 103 3.5 Mailboxes.............................................. 106 3.6 Routing................................................ 111 3.7 Building Finite State Machine
    [Show full text]
  • Applying the Proactor Pattern to High-Performance Web Servers
    APPLYING THE PROACTOR PATTERN TO HIGH-PERFORMANCE WEB SERVERS James Hu Irfan Pyarali Douglas C. Schmidt [email protected],edu [email protected] [email protected] Department of Computer Science, Washington University St. Louis, MO 63130, USA This paper is to appear at the 10th International Confer- 1 INTRODUCTION ence on Parallel and Distributed Computing and Systems, IASTED, Las Vegas, Nevada, October 28-31, 1998. Computing power and network bandwidth on the Internet has increased dramatically over the past decade. High- speed networks (such as ATM and Gigabit Ethernet) and high-performance I/O subsystems (such as RAID) are be- ABSTRACT coming ubiquitous. In this context, developing scalable Web servers that can exploit these innovations remains a Modern operating systems provide multiple concurrency key challenge for developers. Thus, it is increasingly im- mechanisms to develop high-performance Web servers. portant to alleviate common Web server bottlenecks, such Synchronous multi-threading is a popular mechanism for as inappropriate choice of concurrency and dispatching developing Web servers that must perform multiple oper- strategies, excessive filesystem access, and unnecessary ations simultaneously to meet their performance require- data copying. ments. In addition, an increasing number of operating sys- Our research vehicle for exploring the performance im- tems support asynchronous mechanisms that provide the pact of applying various Web server optimization tech- benefits of concurrency, while alleviating much of the per- niques is the JAWS Adaptive Web Server (JAWS) [1]. JAWS formance overhead of synchronous multi-threading. is both an adaptive Web server and a development frame- This paper provides two contributions to the study of work for Web servers that runs on multiple OS platforms high-performance Web servers.
    [Show full text]
  • Leader/Followers
    Leader/Followers Douglas C. Schmidt, Carlos O’Ryan, Michael Kircher, Irfan Pyarali, and Frank Buschmann {schmidt, coryan}@uci.edu, {Michael.Kircher, Frank.Buschmann}@mchp.siemens.de, [email protected] University of California at Irvine, Siemens AG, and Washington University in Saint Louis The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, de- multiplex, dispatch, and process service requests that occur on these event sources. Example Consider the design of a multi-tier, high-volume, on-line transaction processing (OLTP) system. In this design, front-end communication servers route transaction requests from remote clients, such as travel agents, claims processing centers, or point-of-sales terminals, to back-end database servers that process the requests transactionally. After a transaction commits, the database server returns its results to the associated communication server, which then forwards the results back to the originating remote client. This multi-tier architecture is used to improve overall system throughput and reliability via load balancing and redundancy, respectively.It LAN WAN Front-End Back-End Clients Communication Servers Database Servers also relieves back-end servers from the burden of managing different communication protocols with clients. © Douglas C. Schmidt 1998 - 2000, all rights reserved, © Siemens AG 1998 - 2000, all rights reserved 19.06.2000 lf.doc 2 Front-end communication servers are actually ``hybrid'' client/server applications that perform two primary tasks: 1 They receive requests arriving simultaneously from hundreds or thousands of remote clients over wide area communication links, such as X.25 or TCP/IP.
    [Show full text]
  • A Survey of Architectural Styles.V4
    Survey of Architectural Styles Alexander Bird, Bianca Esguerra, Jack Li Liu, Vergil Marana, Jack Kha Nguyen, Neil Oluwagbeminiyi Okikiolu, Navid Pourmantaz Department of Software Engineering University of Calgary Calgary, Canada Abstract— In software engineering, an architectural style is a and implementation; the capabilities and experience of highest-level description of an accepted solution to a common developers; and the infrastructure and organizational software problem. This paper describes and compares a selection constraints [30]. These styles are not presented as out-of-the- of nine accepted architectural styles selected by the authors and box solutions, but rather a framework within which a specific applicable in various domains. Each pattern is presented in a software design may be made. If one were to say “that cannot general sense and with a domain example, and then evaluated in be called a layered architecture because the such and such a terms of benefits and drawbacks. Then, the styles are compared layer must communicate with an object other than the layer in a condensed table of advantages and disadvantages which is above and below it” then one would have missed the point of useful both as a summary of the architectural styles as well as a architectural styles and design patterns. They are not intended tool for selecting a style to apply to a particular project. The to be definitive and final, but rather suggestive and a starting paper is written to accomplish the following purposes: (1) to give readers a general sense of several architectural styles and when point, not to be used as a rule book but rather a source of and when not to apply them, (2) to facilitate software system inspiration.
    [Show full text]
  • The Need for Hardware/Software Codesign Patterns - a Toolbox for the New Digital Designer
    The need for Hardware/Software CoDesign Patterns - a toolbox for the new Digital Designer By Senior Consultant Carsten Siggaard, Danish Technological Institute May 30. 2008 Abstract Between hardware and software the level of abstraction has always differed a lot, this is not a surprise, hardware is an abstraction for software and the topics which is considered important by either a hardware developer or a software developer are quite different, making the communication between software and hardware developers (or even departments) difficult. In this report the software concept of design patterns is expanded into hardware, and the need for a new kind of design pattern, The Digital Design Pattern, is announced. Copyright © 2008 Danish Technological Institute Page 1 of 20 Contents Contents ............................................................................................................................................... 2 Background .......................................................................................................................................... 4 What is a design pattern ....................................................................................................................... 4 Three Disciplines when using Design Patterns ................................................................................ 5 Pattern Hatching ........................................................................................................................... 6 Pattern Mining.............................................................................................................................
    [Show full text]
  • Pentest-Report Mailvelope 12.2012 - 02.2013 Cure53, Dr.-Ing
    Pentest-Report Mailvelope 12.2012 - 02.2013 Cure53, Dr.-Ing. Mario Heiderich / Krzysztof Kotowicz Index Introduction Test Chronicle Methodology Vulnerabilities MV -01-001 Insufficient Output Filtering enables Frame Hijacking Attacks ( High ) MV -01-002 Arbitrary JavaScript execution in decrypted mail contents ( High ) MV -01-003 Usage of external CSS loaded via HTTP in privileged context ( Medium ) MV -01-004 UI Spoof via z - indexed positioned DOM Elements ( Medium ) MV -01-005 Predictable GET Parameter Usage for Connection Identifiers ( Medium ) MV -01-006 Rich Text Editor transfers unsanitized HTML content ( High ) MV -01-007 Features in showModalDialog Branch expose M ailer to XSS ( Medium ) MV -01-008 Arbitrary File Download with RTE editor filter bypass ( Low ) MV -01-009 Lack of HTML Sanitization when using Plaintext Editor ( Medium ) Miscellaneous Issues Conclusion Introduction “Mailvelope uses the OpenPGP encryption standard which makes it compatible to existing mail encryption solutions. Installation of Mailvelope from the Chrome Web Store ensures that the installation package is signed and therefore its origin and integrity can be verified. Mailvelope integrates directly into the Webmail user interface, it's elements are unintrusive and easy to use in your normal workflow. It comes preconfigured for major web mail provider. Mailvelope can be customized to work with any Webmail.”1 1 http :// www . mailvelope . com /about Test Chronicle • 2012/12/20 - XSS vectors in common input fields (Mailvelope options etc.) • 2012/12/20 -
    [Show full text]
  • Faster Base64 Encoding and Decoding Using AVX2 Instructions
    Faster Base64 Encoding and Decoding using AVX2 Instructions WOJCIECH MUŁA, DANIEL LEMIRE, Universite´ du Quebec´ (TELUQ) Web developers use base64 formats to include images, fonts, sounds and other resources directly inside HTML, JavaScript, JSON and XML files. We estimate that billions of base64 messages are decoded every day. We are motivated to improve the efficiency of base64 encoding and decoding. Compared to state-of-the-art implementations, we multiply the speeds of both the encoding (≈ 10×) and the decoding (≈ 7×). We achieve these good results by using the single-instruction-multiple-data (SIMD) instructions available on recent Intel processors (AVX2). Our accelerated software abides by the specification and reports errors when encountering characters outside of the base64 set. It is available online as free software under a liberal license. CCS Concepts: •Theory of computation ! Vector / streaming algorithms; General Terms: Algorithms, Performance Additional Key Words and Phrases: Binary-to-text encoding, Vectorization, Data URI, Web Performance 1. INTRODUCTION We use base64 formats to represent arbitrary binary data as text. Base64 is part of the MIME email protocol [Linn 1993; Freed and Borenstein 1996], used to encode binary attachments. Base64 is included in the standard libraries of popular programming languages such as Java, C#, Swift, PHP, Python, Rust, JavaScript and Go. Major database systems such as Oracle and MySQL include base64 functions. On the Web, we often combine binary resources (images, videos, sounds) with text- only documents (XML, JavaScript, HTML). Before a Web page can be displayed, it is often necessary to retrieve not only the HTML document but also all of the separate binary resources it needs.
    [Show full text]
  • Migrating-To-Red-Hat-Amq-7.Pdf
    Red Hat AMQ 2021.Q2 Migrating to Red Hat AMQ 7 For Use with Red Hat AMQ 2021.Q2 Last Updated: 2021-07-26 Red Hat AMQ 2021.Q2 Migrating to Red Hat AMQ 7 For Use with Red Hat AMQ 2021.Q2 Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • World-Wide Web Proxies
    World-Wide Web Proxies Ari Luotonen, CERN Kevin Altis, Intel April 1994 Abstract 1.0 Introduction A WWW proxy server, proxy for short, provides access to The primary use of proxies is to allow access to the Web the Web for people on closed subnets who can only access from within a firewall (Fig. 1). A proxy is a special HTTP the Internet through a firewall machine. The hypertext [HTTP] server that typically runs on a firewall machine. server developed at CERN, cern_httpd, is capable of run- The proxy waits for a request from inside the firewall, for- ning as a proxy, providing seamless external access to wards the request to the remote server outside the firewall, HTTP, Gopher, WAIS and FTP. reads the response and then sends it back to the client. cern_httpd has had gateway features for a long time, but In the usual case, the same proxy is used by all the clients only this spring they were extended to support all the within a given subnet. This makes it possible for the proxy methods in the HTTP protocol used by WWW clients. Cli- to do efficient caching of documents that are requested by ents don’t lose any functionality by going through a proxy, a number of clients. except special processing they may have done for non- native Web protocols such as Gopher and FTP. The ability to cache documents also makes proxies attrac- tive to those not inside a firewall. Setting up a proxy server A brand new feature is caching performed by the proxy, is easy, and the most popular Web client programs already resulting in shorter response times after the first document have proxy support built in.
    [Show full text]
  • Play Framework Documentation
    Play framework documentation Welcome to the play framework documentation. This documentation is intended for the 1.1 release and may significantly differs from previous versions of the framework. Check the version 1.1 release notes. The 1.1 branch is in active development. Getting started Your first steps with Play and your first 5 minutes of fun. 1. Play framework overview 2. Watch the screencast 3. Five cool things you can do with Play 4. Usability - details matter as much as features 5. Frequently Asked Questions 6. Installation guide 7. Your first application - the 'Hello World' tutorial 8. Set up your preferred IDE 9. Sample applications 10. Live coding script - to practice, and impress your colleagues with Tutorial - Play guide, a real world app step-by-step Learn Play by coding 'Yet Another Blog Engine', from start to finish. Each chapter will be a chance to learn one more cool Play feature. 1. Starting up the project 2. A first iteration of the data model 3. Building the first screen 4. The comments page 5. Setting up a Captcha 6. Add tagging support 7. A basic admin area using CRUD 8. Adding authentication 9. Creating a custom editor area 10. Completing the application tests 11. Preparing for production 12. Internationalisation and localisation The essential documentation Generated with playframework pdf module. Page 1/264 Everything you need to know about Play. 1. Main concepts i. The MVC application model ii. A request life cycle iii. Application layout & organization iv. Development lifecycle 2. HTTP routing i. The routes file syntax ii. Routes priority iii.
    [Show full text]
  • The Netty Project 3.2 User Guide the Proven Approach to Rapid Network
    The Netty Project 3.2 User Guide The Proven Approach to Rapid Network Application Development 3.2.6.Final Preface .............................................................................................................................. iii 1. The Problem ........................................................................................................... iii 2. The Solution ........................................................................................................... iii 1. Getting Started ............................................................................................................... 1 1.1. Before Getting Started ............................................................................................ 1 1.2. Writing a Discard Server ......................................................................................... 1 1.3. Looking into the Received Data ................................................................................ 3 1.4. Writing an Echo Server ........................................................................................... 4 1.5. Writing a Time Server ............................................................................................ 5 1.6. Writing a Time Client ............................................................................................. 7 1.7. Dealing with a Stream-based Transport ...................................................................... 8 1.7.1. One Small Caveat of Socket Buffer ................................................................
    [Show full text]
  • Edgex: Edge Replication for Web Applications
    EdgeX: Edge Replication for Web Applications by Hemant Saxena A thesis presented to the University of Waterloo in fulfillment of the thesis requirement for the degree of Master of Mathematics in Computer Science Waterloo, Ontario, Canada, 2015 c Hemant Saxena 2015 I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. ii Abstract Global web applications face the problem of high network latency due to their need to communicate with distant data centers. Many applications use edge networks for caching images, CSS, javascript, and other static content in order to avoid some of this network latency. However, for updates and for anything other than static content, communication with the data center is still required, and can dominate application request latencies. One way to address this problem is to push more of the web application, as well the database on which it depends, from the remote data center towards the edge of the network. This thesis presents preliminary work in this direction. Specifically, it presents an edge-aware dynamic data replication architecture for relational database systems supporting web applications. The objective is to allow dynamic content to be served from the edge of the network, with low latency. iii Acknowledgements I am extremely grateful to my supervisor Ken Salem for his guidance, support, and dedication throughout this thesis and during my graduate studies. His training and enthu- siasm towards addressing challenging problems has had a positive effect in my life.
    [Show full text]