BEP TI3806 Creating an Online Auctioning Clock

BEP TI3806 Creating an online auctioning clock Authors W.J. Baartman C. Lemaire M.J. van Tartwijk P.W.P. van der Stel J.C. de Vries BEP TI3806 Creating an online auctioning clock To obtain the degree of Bachelor of Science at the Delft University of Technology, to be presented and defended publicly on Tuesday July 2, 2019 at 11:00 AM. Authors: W.J. Baartman C. Lemaire M.J. van Tartwijk P.W.P. van der Stel J.C. de Vries Project duration: April 23, 2019 – July 5, 2019 Guiding committee: Robin van den Broek Developer @ JEMid, Client Jill van der Knaap Marketing/Communication @ JEMid, Client Dr. Annibale Pannichella TU Delft, Coach Dr. Huijuan Wang Bachelor Project Coordinator Preface This report announces the end of studying at the Delft University of Technology for the Bachelor’s degree in Computer Science and Engineering. Although the end of this stage in growing up to be a computer scientist or engineer is near, most of us will continue our time at TU Delft with great pleasure during a followup master of Computer Science. In this report, we will discuss the product we created during the last ten weeks and we will touch upon the methods and knowledge we used to produce it. Before we lay out the technical details of our final product, we would like to thank those who made our path to it possible. First of all, we would like to thank JEMid for their hospitality and enthusiasm. After arranging to do a project we like for them, JEMid offered us a beautiful workplace in their office. We would like to thank Robin van den Broek and Jill van der Knaap in particular for helping us with external and internal communications, and for providing us with the data required. We would like to thank Annibale Panichella from the faculty of EEMCS at TU Delft for his guidance and for sharing his insights. Finally, we dedicate this report to Johanna Sijgje Goemaat who came to pass so unexpectedly in the morning of the 12th of June 2019. We give Wesley our best wishes with recovering from this terrible loss. Delft, July 2019 i Summary For this project, JEMid tasked us with creating a proof of concept of a new online auction in the form of a web application for Royal FloraHolland. JEMid is a software company operating in the agricul tural domain. The preexisting digital auction is not available as a web application and has generated technical debt over the past twenty years of it is existence. The main challenge of the project was to make sure the application is capable of sufficiently handling the current load of the auction while maintaining similar performance. This translates to a stable con nection with a ping of fewer than 30 milliseconds for clients within the Netherlands. On top of that, the system had to be scalable to support higher numbers of buyers in the future. We used a microser vice architecture able to balance the load over several servers to resolve this. We spread the load of communicating with clients to services separate from the main application service. This allowed the main application service to solely and adequately keep track of the state of the clock and determine the winner of a session. To validate that we indeed achieved the main goals of the project, we created a simulation that would simulate any number of clients connecting to the clock auction and placing bids. In this process, we generated buyer and auctioneer behaviour by analysing transaction data. We extracted several distri butions from the data and sampled from it to make it more realistic. In the end, we ran this simulation ten times for chunks of an auction with 610 connected clients. A few peaks showed up where pings from client to server were significantly higher than usual. However, in the long run, the system showed low standard deviations in ping, meaning the general consistency was high. Overall, the results we gathered showed that our application was able to deal with 610 connected clients. In the end, we consider our project to be a success. First of all, we showed that a clock application in the browser can be implemented with seven weeks of development time. Secondly, we showed that such an application could handle a realistic amount of traffic without much trouble, given sufficient computing resources. These two accomplishments show that replacing the current clock application with a webbased application is feasible. ii Contents 1 Introduction 1 2 Problem definition 2 3 Problem analysis 3 3.1 Buyers. 3 3.2 Auctioneer . 4 3.3 JEMid. 4 3.3.1 The UI. 5 3.3.2 Backend features . 6 3.3.3 Future expansions . 6 3.4 Floriday . 6 3.5 Conflicting requirements . 6 4 Design 8 4.1 Requirements. 8 4.1.1 Functional requirements . 8 4.1.2 Nonfunctional requirements . 9 4.2 Design goals . 10 4.3 Architecture . 11 4.3.1 Components . 11 4.3.2 Control . 12 5 Implementation 13 5.1 Flow . 13 5.1.1 Initialisation . 13 5.1.2 Auction process. 14 5.2 Winner selection . 15 5.3 SignalR communication . 16 5.3.1 Incoming messages . 16 5.3.2 Outgoing messages . 18 5.4 Security . 19 5.4.1 Authentication and authorization. 20 5.4.2 Privilege enforcement . 20 6 Simulation 21 6.1 Setup . 21 6.1.1 Weaknesses and limitations . 22 6.1.2 Hardware and configurations . 23 6.2 Distributions. 23 6.2.1 Distribution of the bidding price . 24 6.2.2 Distribution of the bought quantity . 24 6.2.3 Distribution of the increase price. 28 6.2.4 Distribution of simultaneous buyers . 29 6.3 Scheduler . 29 6.4 Results . 33 7 Evaluation 37 7.1 Process . 37 7.1.1 Workflow . 37 7.1.2 Client interaction . 37 iii CONTENTS iv 7.2 Product . 37 7.2.1 Features and requirements . 38 7.2.2 Client satisfaction. 38 7.2.3 Code quality . 39 7.3 Performance . 39 8 Ethics 41 8.1 Jobs . 41 8.2 Financial aspects . 41 8.3 Data . 42 9 Discussion and recommendations 43 9.1 The clock system . 43 9.2 Simulation. 43 10 Conclusion 45 A Original problem statement 47 B Product Plan 49 B.1 Introduction . 49 B.2 Purpose . 50 B.2.1 Research phase goals . 50 B.2.2 Product goals . 50 B.2.3 Functional requirements . 50 B.2.4 Nonfunctional requirements . 51 B.2.5 Deliverables. 51 B.3 Process . 52 B.3.1 Communication . 52 B.3.2 Workflow . 52 B.4 Risks . 52 B.4.1 Team problems . 53 B.4.2 Expected design is infeasible . 53 B.4.3 Inadequate research . 53 B.5 Planning. 53 C Research Report 55 C.1 Introduction . 55 C.2 Problem analysis . 55 C.2.1 Current auction . 55 C.2.2 JEMid. 57 C.2.3 Floriday . 59 C.2.4 Conflicting requirements . 59 C.3 Technologies . 60 C.3.1 Tooling and deployment . 60 C.3.2 Clock API . 60 C.3.3 Realtime communication service . 62 C.3.4 Graphical user interface . 62 C.3.5 Simulations . ..

Load more