Transcription
Vol.7/No.2 (2015)INTERNETWORKING INDONESIA JOURNAL15Asynchronous Publish/Subscribe ArchitectureOver WebSocket for Building Real-timeWeb ApplicationsJastian Ganaputra and Bens PardameanBina Nusantara University, Jakarta Abstract — This study applied the Publish/Subscribearchitectural pattern utilizing Amazon Simple Queue Service as amessage broker to facilitate the Publish/Subscribe architectureon HTML5 featuring the WebSocket protocol for the transportlayer. The application of the Publish/Subscribe pattern onWebSocket connections resolved the issue of lost messages onWebSocket connections. The framework performances werecompared to WebSocket connections itself with regards tomessages loss, response latency times, and bandwidth networkout. The results revealed that the proposed framework in thisstudy led to message loss reduction.Index Terms — WebSocket, HTML5, Publish/Subscribe,Message BrokerI. INTRODUCTIONDURINGwebtechnology growth, the use of real-time databy web applications will increase in the coming years [1].The need for real-time websites will subsequently increase;this includes the features of simple use-cases for real-time webapplication approaches in data display, statistics, dashboardmonitoring, notifications, instant messaging, and nformation/messages to clients rather than a simultaneousrequest to server for updates can lead to a much differenttechnical architecture. Building a real time web applicationrequires a connection that provides two-way communicationswith minimum response latency time, which leads to a moreresponsive user interaction. The application must also have aserver capable of handling message interchanges with clients.A. WebSocketThis study’s approach to building a real-time webapplication utilizes WebSocket, a protocol that provides fullduplex communications channels over a single TCPconnection. The WebSocket protocol by provides astandardized way for the server to send content to the browserwithout client solicitation as the trigger. Messages can also bepassed bi-directionally between a browser and the server whilemaintaining an open connection. Additionally, some earlyadopters of WebSocket technology have raised concernsregarding WebSocket’s compatibility with Enterprise WebMiddleware Infrastructures (EWMI), such as proxy servers,load balancers, firewalls, message brokers, etc [1].Relative to the HTTP protocol, WebSocket protocolprovides better latency time [2]. The process of datatransmission through WebSocket connection is not impervioustowards data loss, especially with the increasing number ofconnections. When a WebSocket session fails, the protocoldoes not have the ability to resolve and define messages asthose that have been received and those that have been lost[3]. Therefore, distributed applications and more complexlogic processes among applications require a model that canmanage the distribution of notifications/messages to clientsbased on constraints specified upon subscription.B. Publish/SubscribeThe Publish/Subscribe pattern is a paradigm providesasynchronous communications for the distributed systemclass. Message Broker is an architecture that mediatescommunication among applications based on thePublish/Subscribe pattern for message validation, messagetransformation, and message routing. Publish/Subscribesystems facilitate users with the ability to express their interestin a subscription and subsequently receive notifications basedon their interests for any publisher-generated events [4].Fig.1 Publish/Subscribe Schema [5]As shown in Figure 1, the publisher issues or post messagesto the message broker. Subscribers must register with aspecific message broker of that performs the task of relayingrelevant messages from publishers to subscribers.ISSN: 1942-9703 / 2015 IIJ
16INTERNETWORKING INDONESIA JOURNALC. Problem FormulationWith an increase in the number of WebSocket connections,data loss becomes a confounding problem. However, there isno protocol that addresses and defines data loss during datatransmission processes between server and clients.D. HypothesesThe hypotheses are stated as follows:H1: Applying Publish/Subscribe pattern method reducesmessage loss during message transmission on WebSocketconnections;H2: Applying Publish/Subscribe pattern method increasesthe response latency time of WebSocket connections;H3: Applying Publish/Subscribe pattern increases thebandwidth network out of WebSocket connections.II. RELATED WORKSPrevious studies have proposed model solutions related toWebSocket connection and compare them to various methodsused for real-time data communication. Through comparativeanalyses, WebSocket is found to be a protocol that providesefficient communications between Web Servers and Clientswith the lowest response latency time relative to HTTPPolling, AJAX long polling, COMET, HTTP Streaming, andWebSocket [2,6]. Pimentel and Nickerson [7] compare oneway latency between a client and server using various methodssuch as polling and long polling with WebSocket usingWindComm application.Alamsi and Kuma [1] evaluate the performance ofWebSocket, showing that WebSocket not only contributes lessdata transmission over the network but also significantlysimplifies development by abstracting the sending andreceiving of data. Additionally, the Publish/Subscribearchitecture provides better scalability [8] and reliability toavoid message congestion, conflict, and loss [9].Khanaferov identifies the best approach for developingasynchronous web applications [10]. The study proposes anasynchronous Publish/Subscribe framework solution by usingJava Message Service as a Message Broker. A similarapproach is also used by Roussele [11]. Khanaferovimplements the Java Applet plug-in towards the asynchronousserver push transport layer [10]. The resulting frameworkconsists of a Publish/Subscribe pattern to facilitate anasynchronous message passing interface. However, data lossdue to concurrent increase of user request remains unresolved,leading to this study’s hypotheses and problem formulations.Publish/Subscribe model and the WebSocket connection on itsown (without the Publish/Subscribe model). The resultingmodel can serve as a guide for web developers in designing areal-time, web-based application.A. Study DesignTo conduct the experiment, two web application serverswere built for transmitting messages. The first experimentalapplication server was built over WebSocket withoutimplementing Publish/Subscribe pattern method while thesecond experimental application server was implemented withthe Publish/Subscribe pattern method. The technology usedfor both of applications was identical since WebSockettechnology is a feature in HTML5. This study used HTML5for content structuring and presentation for webs that supportWebSocket connection. Javascript code was used for theclient-side programming and connection establishment. Theserver-side programming utilized Microsoft ASP.NET, pment to produce dynamic web pages with easydevelopment and deployment. Microsoft ASP.NET alsopossessed many features, tools, and classes that reduce codingefforts. AWS SQS (Amazon Web Service Simple QueueService) was used as a message broker to implement thePublish/Subscribe pattern.Both experimental scenarios were conducted with 30 testingiterations. Every set of iteration was divided into thefollowing: 50 messages from 50 concurrent users; 100 messages from 100 concurrent users; 500 messages from 500 concurrent users; 1,000 messages from 1,000 concurrent users; 5,000 messages from 5,000 concurrent users; 10,000 messages from 10,000 concurrent users.To simulate up to 10,000 users request, a third-party tool,Loader.io was used. Loader.io is an open-source, web-basedapplication that allows clients to stress-test applications.The output results from both experimental scenarios wereresponse latency time, messages sent with responses, andbandwidth network out. The output data were then processedand statistically analyzed.III. METHODOLOGYThis study was quantitative in nature with the intent todetermine web application architecture’s performance andeffectiveness in providing proposed solutions for buildingreal-time, web-based applications. Measurements included theobserved difference in response latency time between theproposedsolutionofWebSocketwithappliedGANAPUTRA & PARDAMEANFig.2 Concurrent Users Test DiagramISSN: 1942-9703 / 2016 IIJ
Vol.7/No.2 (2015)INTERNETWORKING INDONESIA JOURNALFigure 2 shows the method by which the test worked. Eacharrow represents a client making requests to the web server.The length of the arrow represents the response time for aclient to access the server in a given test.B. Testing EnvironmentThe testing environment was run in the cloud computingplatform, Amazon Elastic Compute Cloud (AWS EC2). Theserver host operating system assigned dedicated CPU coresand was configured with the following specifications: Operating System: Windows Server 2012 R2 Standard 64-bit Processor: Intel Xeon CPU E5-2670 v2 @ 2.50GHz Memory: 1024 MB RAMApplication Server Environment: Internet Information Services 8 Application Server Manager .Net Framework 4.5Testing tools: Internet Explorer 11 Loader.io SolarWinds Real-Time Bandwidth MonitorC. Data CollectionTo collect the data for analysis, simulations were conductedby establishing environments in web application servers, onewith Publish/Subscribe pattern application on WebSocket andone without the Publish/Subscribe pattern application. Forboth environments, the tests were performed by sendingmessages from clients. The output results of the tests were thedata used for analysis.D. Analytical MethodThe study used independent t-test statistical analysis. TheT-test analysis compared the response latency time betweenthe two experimental groups. The same test was used to viewthe bandwidth network out as influenced by the application ofPublish/Subscribe pattern on WebSocket connectionIV. RESULTA. Data LossData Loss was analyzed by comparing total response countsof messages sent to server and success response counts.Table 1 shows the result of response success per responsesent with 30 iterations for different concurrent users. Thesuccess rate was calculated from the total of success responsedivided by the total request sent. The data loss rate wascalculated from 100% minus success rate in percent.Based on Table 1, it can be seen that data loss is nonexistent in the first two cases of Group 1 (without17Publish/Subcribe). For the third case with 500 concurrentconnections, a 0.74% rate of data loss occurred. Furthermore,under higher load connections (with 1,000, 5,000, and 10,000concurrent connections), the data loss ratio increasedconcurrently. For Group 2 (with Publish/Subcribe), data lossesoccurred once the concurrent users connection reached 5,000,though the success rate is higher than that of Group 1. For the10,000 connections case, Group 2 data loss was reduced byover 7% relative to Group 1. Despite this improvement, Group2 still experienced data loss. However, the lost messages canbe re-queued to AWS SQS message broker, delegating thetask of handling data loss problem to the message broker forresolution.Since Group 2 with the application of Publish/Subscribepattern has no messages loss for 50, 100, 500, and 1,000TABLE IDATA LOSS COMPARISON BETWEEN GROUPSConcurrentUsersGroup 1(without Pub/Sub)SuccessLossGroup 2(with rrent users, independent t-test method was used tocompare the two groups for 5,000 concurrent usersconnections and 10,000 concurrent users connections, asshown in Table 2.With p-value of less than alpha-level of 0.05 for 5,000concurrent users and 10,000 concurrent users, Hypothesis H1was accepted. In other words, applying Publish/Subscribepattern to WebSocket significantly reduced data loss duringmessage transmission processes on WebSocket connections.B. Response Latency TimesResponse latency analysis was calculated by measuring thedifference in time stamps between the messages was sent andwhen the client received the message.Figure 3 shows the sequence of ‘get timestamp’ to calculatethe response latency time. Timestamp was retrieved beforesending messages to server then retrieved again when asubscribing client received the messages.Table 3 shows the result of the response latency t-test forTABLE IIDATA LOSS T-TEST RESULT BETWEEN GROUPSConcurrentUsersN5,0003010,00030*significant at p 0.05Group 1 (without Publish/Subscribe)MeanStd. Deviation(Total Data Lost)285829.202.4518.62NGroup 2 (with Publish/Subscribe)MeanStd. Deviation(Total Data Lost)3030ISSN: 1942-9703 / 2015 IIJ4985.201.732.23p-value(α 0.05) 0.05* 0.05*
18INTERNETWORKING INDONESIA JOURNALGroup 1 and Group 2 for each test case of 50, 100, 500, 1,000,5,000, and 10,000 concurrent users with each test caseconducted in 30 iterations.Fig.3 Get Time Stamp Sequence DiagramFor the 50 concurrent users case, Group 2 withPublish/Subscribe pattern has a higher response latency meanvalue with an approximate difference of 1.17 milliseconds.However, the standard deviation of Group 2 is lower thanstandard deviation of Group 1, indicating that the former amore stable response latency time across the 30 iterations. Thep-value of 0.06168 is higher than the 0.05 alpha level. Thus,there is no significant difference in response latency timesbetween the two groups for 50 concurrent users connections.For 100 concurrent users case, Group 2 also has a higherresponse latency mean value but a lower standard deviationGANAPUTRA & PARDAMEANthan Group 1. The p-value of 0.05681 is greater than 0.05alpha level, rendering an interpretation of no significantdifference of response latency times between Group 1 andGroup 2 for 100 concurrent users connections.For ea
Middleware Infrastructures (EWMI), such as proxy servers, load balancers, firewalls, message brokers, etc [1]. Relative to the HTTP protocol, WebSocket protocol provides better latency time [2]. The process of data transmission through WebSocket connection is not impervious
