The Internet is based on communication and information exchange between users. One of the most important functions that this network provides us with is the ability to communicate with other people in real time, regardless of the location of the interlocutor. This paper focuses on existing approaches to implementing instant messaging in web applications. The goal of this research is to analyze existing protocols and technologies for instant messaging, describe their advantages and principles of work, select approaches for comparison and measurement criteria. This paper documents the process of comparison, as well as provides justification of the evaluation results and gives recommendation on their basis. Computer-mediated communication, Web applications, instant messaging, WebSocket, serverCOLINS-2023: 7th International Conference on Computational Linguistics and Intelligent Systems, April 20-21, 2023, Kharkiv, Ukraine ORCID: 0000-0002-8161-552X (N. Sharonova); 0000-0002-7686-6439 (I I. Kyrychenko); 0009-0007-0580-7902 (D. Shapovalova)
sent events, long polling, short polling, client pull, server push
Today, the Internet has become an integral part of most people’s everyday lives. The technologies that use this network and the opportunities that they provide to users are rapidly developing and changing every day. The basis of this network is to ensure communication and exchange of information between users. One of the most important functions that the Internet provides is the ability to communicate with other people in real time, regardless of the location of the interlocutor.
There are several different approaches to ensuring online communication between people. One of the earliest and most widespread is email. Email addresses are required to register for many services on the Internet, and it is generally assumed that every user on the Internet has at least one email address. When using email, user can write a letter and send it to the recipient's email address. The letter will be sent, and the user will receive a reply after a certain time. There are different advantages and disadvantages of using email addresses for communication. Among its advantages, we can highlight the following:
Ubiquity: email is ubiquitous and is used by individuals and businesses around the world. Most people have an email address, making it a convenient and efficient way to communicate with a wide range of people;
Convenience: email can be accessed from anywhere with an internet connection, allowing users to send and receive messages at their convenience. It also allows users to send attachments such as documents, images, and videos;
Record keeping: email messages can be saved and archived, making it easy to keep track of communication and reference old messages if needed;
2023 Copyright for this paper by its authors. 4. Formality: email provides a formal mode of communication that is appropriate for professional and business settings; 5. Reduced cost: email is typically less expensive than traditional mail and phone calls, making it a cost-effective means of communication.
However, email communication also has its disadvantages: 1. Spam: email is often plagued by spam messages, which can clog up inboxes and make it difficult to manage communication; 2. Security: email messages can be intercepted and hacked, making it essential to use secure channels and encryption to protect sensitive information; 3. Misinterpretation: email messages can be misinterpreted, leading to confusion, misunderstandings, and potential conflicts; 4. Overload: email overload can be a problem, with many people receiving too many messages and struggling to keep up with their inbox; 5. Lack of immediate feedback: email messages are asynchronous, meaning that there can be delays in responses, making it difficult to have immediate feedback or conversations.
Email is a useful tool for communication, but it has some disadvantages that can make it challenging to use effectively. This method is still working, but over time, other technologies have emerged that are more convenient to use.
Another way to communicate online is through forums. A forum is a type of website where members can post questions, start discussions, or participate in various discussions. Each individual question or discussion is called a topic. A forum is usually updated and monitored by an administrator or moderator. Online forums can help build a sense of community among users who share common interests or goals. Forums are an excellent source of information on a variety of topics. Users can ask questions, share their knowledge and expertise, and receive feedback and advice from other members of the community. Online forums can facilitate collaboration among members of a community, allowing users to work together on projects, share ideas, and provide feedback to each other.
One of the most common ways to communicate today is through Instant Messaging (IM). It is a form of text-based communication in which two or more people engage in a single conversation via their computers or mobile devices in an online chat room. It differs from the commonly accepted definition of chat, in which user participates in a more public, real-time conversation in a chat room where everyone on the channel can see everything that all other users are saying.
In its simplest form, instant messaging seeks to accomplish two goals: availability monitoring to send availability notifications to chat users and messaging. The software relies on a central server or servers to monitor presence. When a user logs in to an instant messaging system, their login is recognized and other online users who have that address listed as a "buddy" or friend receive notifications of the user's presence. The software establishes a direct connection between users so that they can communicate with each other synchronously in real time.
There are several different approaches to providing instant messaging. All of them fulfill their purpose and provide real-time communication between users: messages in chats appear as soon as the other person sends them, and the conversation can take place without delay. But each of the existing approaches implements this communication in a different way.
The main types of instant messaging implementation are client pull and server push. Each of these approaches has several different implementations, which will be discussed in this paper.
The purpose of this research paper is to compare existing protocols and approaches for implementing instant messaging. Since instant messaging is a popular and widespread technology, the study of ways to implement it in order to identify the most optimal one can be considered relevant in modern realities.
This paper introduces four distinct methods for putting instant chat web systems into practice. It explains what instant messaging is and how it differs from other online communication methods in terms of benefits. This is the first time the problem has been posed in this formulation. This paper introduces four distinct methods for putting instant chat web systems into practice. It explains what instant messaging is and how it differs from other online communication methods in terms of benefits.
Instant messaging tools and chat applications has been around us for some time, so some research has already been conducted.
One of the most recent papers is a research conducted by J. Botha, C. Van ‘t Wout, and L. Leenen
titled “A Comparison of Chat Applications in Terms of Security and Privacy” [
Another similar work was published in “IOP Conference Series: Materials Science and Engineering”
in 2020 by R. M. Ali and S. N. Alsaad [
The article “Securing Instant Messages With Hardware-Based Cryptography and Authentication in
Browser Extension” [
A paper titled “A Model for Social Communication Network in Mobile Instant Messaging Systems”
[
In the paper “Communication-Efficient and Fine-Grained Forward-Secure Asynchronous
Messaging” [
The study “iOS Digital Evidence Comparison of Instant Messaging Apps” [
The purpose of the paper “The Impact of Instant Messaging on the Energy Consumption of Android
Devices” [
The paper titled “OSC-MC: Online Secure Communication Model for Cloud Environment” [
In a recent research “Online Deep Neural Network for Optimization in Wireless Communications”
[
The paper called “Research of Ways to Increase the Efficiency of Functioning Between Firewalls in
the Protection of Information Web-Portals in Telecommunications Networks” [
The research “Formal representation of knowledge for info communication computerized training
systems” [
The paper titled “Metrics applicable for evaluating software at the design stage” [12] reviewed and analyzed the existing metrics used in the software evaluation process at the design stage. Discussed issues related to the selection and accounting of indicators affecting the evaluation of software at the design stage in the management of software development. The study of the metrics used to perform the evaluation of software at the design stage. Found conclusions about the use of the metrics examined in management practice. Proved the need to study the metrics described in the Rada standards governing the process of developing software.
The aim of the article “Beyond First Impressions: Estimating Quality of Experience for Interactive Web Applications” [13] is to examine how waiting time for a user's interactions during a web browsing session can be measured and to establish the correlation between waiting time and user-reported perceived quality, with web maps as a use case. It proposes two new measures: interactive Load Time and Total Completed interactive Load to establish the waiting time associated with a web application user’s interaction.
Another paper called “Holistic Web Application Security Visualization for Multi-Project and MultiPhase Dynamic Application Security Test Results” [14] forms a generic data structure using data sources that are commonly accessible to most web applications. The main contribution of the study is a new dashboard tool that can visually represent the results of dynamic application security tests. The paper also introduces the metrics and measures provided by the tool. Furthermore, a validation study is conducted in which participants are asked to answer quiz questions after using the tool prototype.
The article “Using Server-Sent Events for Event-Based Control in Networked Control Systems” [15] discusses the use of Server-Sent Events (SSEs), a standard HTTP technology that allows communication between a server and a client based on messages sent by the server. SSEs are commonly used in web applications and can be defined with different event triggers that clients can subscribe to. The article proposes the use of SSEs in event-based control strategies, with the plant acting as the server and the controller as the client. The article compares SSEs to other possible solutions and presents a communication workflow between the server and client to define event triggers and subscribe to event streams.
In [16] the authors discuss the difficulties associated with the authentication process and the efforts being made to enhance its usability. Ultimately, recommendations are provided for service providers, along with suggestions for future research.
In the research [17] the author discusses the increased use of technology in education and how instant messaging apps like WhatsApp and WeChat are being used to support language learning. The article focuses on a pilot study that used WeChat as the messaging app and analyzed posts made by students to understand the perceived purposes of using the app for collaboration, peer-support, and knowledge sharing. The findings suggest that WeChat served as a vital link between students, their classmates, and teachers, and was used as a social platform to support the key educational purposes of the program.
Another paper called “Optimization and improvement of bidirectional connections with Web Socket on Synapse framework using Web Workers technology” [18] uses WebSocket connection functionalities to improve connection between devices used for research and highlights performance optimization in comparison to implementation without web workers.
The paper “Gradational Correction Models Efficiency Analysis of Low-Light Digital Image” [19] describes approaches to efficiency comparison and analysis using models of gradation correction when solving actual applied problems of improving the quality of darkened digital images.
In the work [20] the authors point out that end-user devices with multiple access networks can achieve better application performance by distributing traffic across them, but matching application traffic to the most suitable network is challenging due to varying needs and network characteristics. The proposed solution is an application-informed approach for access network selection (IANS), which selects the better access network based on Web resource size and latency and available downstream capacity. IANS was implemented in the Socket Intents prototype and evaluated for Web page loads under different network conditions and for various Web pages. IANS provides the highest speedups in scenarios with asymmetric network conditions and low downstream capacity.
Many of the abovementioned papers make security of communication their main focus. The goal of the current paper is to take security into account as one of the main factors when comparing different instant messaging techniques. Aside from security, we can also define the following criteria to compare by: • Speed. Speed is an important aspect of instant messaging chats because it enables real-time communication and collaboration. Unlike email or other forms of communication, IM allows users to exchange messages quickly and efficiently, allowing for instant feedback and responses. This can be particularly important in business and professional settings where timely communication can make a significant difference in decision-making and productivity. In addition, speed can also enhance social connections and relationships, allowing users to maintain more frequent and meaningful interactions with friends, family, and colleagues. Speed is a key factor in the effectiveness of IM chats and contributes to the convenience, efficiency, and real-time nature of this form of communication. • Difficulty of development. Difficulty of development is an important aspect of instant messaging chats because it affects the resources and expertise required to create and maintain the platform. Developing systems that use instant messaging requires specialized knowledge and skills in areas such as software engineering, networking, and security. The more difficult the development process, the more resources, time, and expertise are required, which can impact the cost and quality of the final product. Additionally, difficulty of development can also affect the speed of updates and improvements to the platform, as well as its ability to adapt to changing technologies and user needs. Therefore, the difficulty of development can impact the competitiveness and sustainability of IM platforms in the market. However, it is worth noting that while difficulty of development is important, it is not the only factor that determines the success and adoption of IM.
There are several different approaches to providing instant messaging. All of them fulfill their purpose and provide real-time communication between users: messages in chats appear as soon as the other person sends them, and the conversation can take place without delay. But each of the existing approaches implements this communication in a different way. The main types of instant messaging implementations are client pull and server push. Each of these approaches has several different implementations, which will be discussed in this paper.
The types of implementation this paper is going to focus on are: • WebSocket-based messaging; • Polling (short and long); • Server-sent events.
Both short and long polling are methods that implement client pull approach. Client pull means that client initiates the update process and asks server for updates at certain regular intervals of time. Websocket messaging and server-sent events, however, are implementations of a different approach called server push. It means, unlike client pull, that the updates are initiated by the server side, where server proactively sends them to the client.
Short polling is a type of communication between a client and a server in which the client repeatedly sends requests to the server to check for updates or new information. In short polling, the client sends a request to the server at regular intervals, asking for any updates or changes since the last request. The server responds immediately with any new information, and the client then processes that information and sends another request after a short interval.
Schematically short polling is presented on Figure 1.
As shown on the figure 1, requests are sent after regular delay and not when new updates appear on the server. Short polling is implemented using AJAX-based timer. The frequency of sending requests for new data depends on the latency that the client can afford in retrieving changed information from the server. Server can either send an empty response or data object in its body. One of the drawbacks of this approach is that sending repeated requests to the server wastes resources as each new incoming connection must be established, the HTTP headers must be passed, a query for new data must be performed, and a response (that often doesn’t contain new data) must be generated and delivered. The connection must be closed and any resources cleaned up [21].
Long polling is another implementation of client requesting updates from the server. It aims to somewhat fix the issue with wasting too many resources that short polling has. Unlike the previous approach, long polling send a request to the server and waits until the server has any updates to send back. This allows us to avoid cases in which multiple requests to the server don’t return any changes.
Long polling attempts to minimize both the latency in server-client message delivery and the use of processing/network resources. The server achieves this by responding to a request only when a particular event that signals an update available, status, or timeout has occurred. Once the server sends a long poll response, typically the client immediately sends a new long poll request. This means that at any given time the server will be holding open a long poll request, to which it replies when new information is available for the client. As a result, the server is able to asynchronously "initiate" communication [22].
Schematically long polling is presented on Figure 2.
Long polling attempts to minimize both the latency in server-client message delivery and the use of processing/network resources. The server achieves this by responding to a request only when a particular event that signals an update available, status, or timeout has occurred. Once the server sends a long poll response, typically the client immediately sends a new long poll request. This means that at any given time the server will be holding open a long poll request, to which it replies when new information is available for the client. As a result, the server is able to asynchronously "initiate" communication.
Now let’s look at the server push implementations. WebSocket is a technology that allows to open a two-way interactive communication session between a client and a server [23]. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections [24]. WebSocket schema is presented on Figure 3.
Server sends updates to the client as soon as they appear, and in the meantime, client doesn’t wait for a response and can send a new one. WebSockets provide a two-way ongoing conversation up until the connection is closed. They do not, however, operate on top of HTTP protocol – instead, they need their own TCP connection to work.
Another implementation of server push approach is called server-sent events. The goal of serversent events is to give the browser a convenient way to receive data from the server without having to ask for it. It’s a specification that defines how servers start sending data to clients after establishing a client connection. This method allows the server to push data in asynchronous way back to the client once the connection has been established. This can be described as a one way “publish-subscribe” model, where client “subscribes” to a specific event and watches its updates once the server sends them [25].
Schematically server-sent events are displayed on Figure 4.
Unlike WebSockets, server-sent events operate on top of HTTP protocol. Once the connection is established, the client registers the event source (a way of “subscribing” to updates). If connection with event source is lost, it can be automatically re-established.
The main difference between WebSockets and server-sent events is that WebSockets allows to have a two-directional communication between client and server meanwhile server-sent events are monodirectional [26].
Overall, the described methods can be summarized using a few key points of their implementations. Check Table 1 to see how they compare with each other.
Now that the main approaches have been selected and described, we can define the methods which are going to be used for comparison and what criteria will we base the comparison on.
As previously mentioned, we can define three major points that can to be compared: security, speed,s and difficulty of development.
To compare security aspects, we need to analyze and specify main vulnerabilities and issues a web application can face. There is no straightforward approach to measure security of application, but we can use a risk assessment methodology that takes into account the severity of security issues and their likelihood of occurrence.
First, let’s specify what security issues we will consider. For this purpose, we can use a standardized framework called OWASP. The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications [27]. For each security issue, we would need to consider the following: • Issue impact – numeric value that represents the severity or priority of issue; • Probability of occurrence – numeric value that represents the likelihood of appearance of an issue. It can be calculated considering spread of this issue in web environment, as well as if the current implementation of instant messaging has a vulnerability for this issue.
There are many things we need to take into account while calculating these points, but a high-level formula to calculate security risk score can be written as following: = ∑ ( ) ∗ ( ), (1) where Sec – security risk score, Imp – issue impact, Prb – probability of occurrence, i – security issue.
When talking about instant messaging in real-time web applications, speed is crucial. It directly affects users’ experience and satisfaction, as well as defines messaging latency.
We can distinguish the following factors when considering speed of an instant messaging application: • Message round trip time: this refers to the time it takes for a message to be sent from one user to another and for the acknowledgement to be received. This includes the time it takes for the message to travel over the network and any delays introduced by the client and server. The lower the message round trip time, the faster the application. • Server response time: This refers to the time it takes for the server to receive and process incoming messages and send responses back to the clients. The lower the server response time, the faster the application. • Client processing time: This refers to the time it takes for the client to receive incoming messages and process them before displaying them to the user. This includes any time spent decoding messages, rendering them in the user interface, and updating the message history. The lower the client processing time, the faster the application.
We will be considering all three of these factors to have an equal priority. Based on that, we can formulate a high-level formula to calculate the speed score for an application:
( ) + ( ) + ( ) (2) ( ) = , where Spd – application speed score, Mrt – message round trip time, Srt – server response time, Cpt – client processing time, app – application.
Lastly, to measure difficulty of development for an application we would also need to specify influential factors (such as availability of frameworks for development, browser support, popular programming languages support, number of available libraries etc.) and use them to calculate a score for each of the implementations we want to compare.
For the purpose of this research, we are going to focus on measuring speed score for each of the implementations mentioned in section 3.
While conducting the experiment, we are going to focus on measuring speed criteria of the following instant messaging implementations: short polling, long polling, WebSocket, server-sent events.
Measuring the speed of an instant messaging web application can help identify potential performance issues that may affect the user experience. The purpose of measuring speed is to determine how quickly messages are delivered between users and the server, and how quickly the application responds to user actions such as sending or receiving messages, displaying notifications, and updating the user interface.
The goal of measuring the speed of an instant messaging web application in a real-world environment is to ensure that users have a seamless and fast messaging experience, which can lead to increased user satisfaction and engagement.
First, we need to prepare our testing environments. For each of the abovementioned approaches, we are going to create a small web application that supports minimal functionality of sending and receiving messages.
We take into account factors, mentioned in section 4: message round trip time, server response time, and client processing time.
In order to measure the effectiveness of each of the indicators, it is necessary to conduct initial measurements and long-term measurements. Initial measurements are those obtained when the system is first launched. Long-term measurements are the indicators measured during further interaction with the system.
We are going to use two values for each of the factors: the initial measurement taken during the first launch, and the long-term measurement which is going to be calculated as an average between values we got during the next three runs.
To implement testing environments, we are going to use python library called Flask. Flask is a web framework that provides libraries to build lightweight web applications in python. It is based on WSGI toolkit and jinja2 template engine. Flask is considered as a micro framework [28]. We also need to identify additional libraries we are going to use to ensure the implementation of each approach.
We are going to create a client and a server for each of the applications and ensure their support of used implementation.
To create client that supports short polling: • Use fetch API – a JavaScript interface for accessing and manipulating parts of the protocol, such as requests and responses. It also provides a global fetch() method that provides an easy, logical way to fetch resources asynchronously across the network [29]; • Implement a getLatestMessages() function that is going to send a GET request to the server to retrieve chat messages; • Implement a sendMessage() function that is going to send a POST request to the server to preserve a new message; • Use setInterval() to call getLatestMessages() with a fixed delay for updates.
To create a server side for short polling: • Implement api endpoint “/api/get_latest_messages” that supports GET requests and returns a list of available chat messages; • Implement api endpoint “/api/send_message” that supports POST requests with message data and preserves new messages.
In order to create a web application that uses long polling, we need to create a new client that also supports fetch API and provides getLatestMessages() and sendMessage() functionality, but instead of using timer to send s new GET request, we send a new GET request on success of the previous one.
To implement a WebSocket instant messaging app, we are going to use SocketIO library. Socket.IO is a library that enables low-latency, bidirectional and event-based communication between a client and a server. It is built on top of the WebSocket protocol and provides additional guarantees like fallback to HTTP long polling or automatic reconnection [30].
To write a client that supports WebSocket implementation, we also need: • Implement event listeners “status” and “message”; • Display new messages once the server sends an update.
On the server side, we need to use an additional flask library that supports SocketIO. We need to add the following logic: • Implement event listeners “text” when client sends a new text; • Emit updated list of messages for client to process.
To create an application that uses server sent events, we need to create a stream of data on the server side and assign client to listen to it. On each new message we should send a request that would trigger a server-sent event and update list of all chat messages.
We are also going to define a custom MessageAnnouncer class that implements the following methods: • listen() – register listeners; • announce – send the incoming message to queue.
Once the testing environments are ready, we need a way to measure time for previously specified criteria. We need to identify a representative use case to base measurements on. Since the applications don’t have a lot of functionality, we are going to use a basic scenario “User opens the chat and sends a message”.
The following rules should be applied during measurements: • Message round trip time – the time between the first click of a “Send message button” until the new message is displayed in the dialog window; • Server response time – the time between when server accepts a new message until an acknowledgement is sent to the client; • Client processing time – the time between when a new message arrives to the client until it’s displayed in the chatroom; • Application speed score – value calculated using formula (2).
For measuring time we are going to use built-in libraries and their methods: datetime.time() and performance.now(). The performance.now() method is a JavaScript API that provides high-resolution timestamps for measuring performance [31]. To measure the speed of an application using performance.now(), we can follow these steps: • Identify the code to be measured: Identify the specific code that we want to measure for performance. This could be a function, a block of code, or an entire script; • Insert performance.now() calls: Insert performance.now() calls at the start and end of the code to be measured. This will capture the timestamp at the beginning and end of the code block. • Calculate the elapsed time: Subtract the start timestamp from the end timestamp to calculate the elapsed time. This will give us the time taken for the code to execute. • Repeat the measurement: To get a more accurate measurement, repeat the measurement several times and calculate the average elapsed time.
Once we have completed to plan the experiment, we can move on to performing the measurements.
Once the testing applications have been created, we can start measuring speed performance for each of selected implementation methods.
After we run the application that uses short polling method, we document the results we get on the first run and on the next three consecutive requests. These measurements are presented in Table 2.
Using these values, we are going to calculate a long-term measurement value by taking the results of consecutive runs and diving them by number of runs: • avg(message round trip time) = 37,466 ms • avg(server response time) = 3 ms • avg(client processing time) = 40,846 ms
These values are added to the Table 2 as well.
Using results of measurement for short polling, we can calculate application speed score with formula (2): • Spd(initial) = 629,866 ms • Spd(long-term) = 81,312 ms
Next, we are going to measure speed of application implemented using long polling technique. The measurements we got after running the chat application and sending messages are presented in Table 3.
In the same way we are going to calculate a long-term measurement value by taking the results of consecutive runs and diving them by number of runs: • avg(message round trip time) = 6,29 ms • avg(server response time) = 3,6 ms • avg(client processing time) = 10,57 ms Application speed score for short polling is as follows: • Spd(initial) = 21,09 ms • Spd(long-term) = 6,82 ms
Next, let’s measure speed of an application that uses WebSocket implementation of a chat application.
The results of measurement are presented in Table 4.
Calculated long-term measurements: • avg(message round trip time) = 7,256 ms • avg(server response time) = 0,13 ms • avg(client processing time) = 7,38 ms Application speed score for short polling is as follows: • Spd(initial) = 7,1 ms • Spd(long-term) = 4,922 ms.
After all of the measurements were taken, we can present final data in resulting Table 6.
Once we finished experiment and got results on different speed scores for each of the instant messaging approaches, we can proceed and analyze what they mean.
While conducting the experiment, we compared four different ways to implement instant messaging technique in terms of their speed score, both on initial run and the consecutive (long-term) runs. The results were summarized and presented in Table 6.
Overall across different implementations we can see that server response time in general tends to be lesser than client processing, regardless of which side initiated the data update (client pull or server push). We can also see that numbers on the initial run tent to be bigger than those on long-term run. This is explained by the fact that we take additional time to establish the connection initially. There can be multiple contributing factors that make the initial run slower than the rest, among them the following: • Server startup time: when a web application is first started, the server may need to perform initialization tasks, such as connecting to a database or loading configuration settings. These tasks may take some time to complete, which can result in a longer initial load time; • Network latency: the first time a user accesses a web application, their browser needs to establish a connection with the server. This process can take some time, especially if there is high network latency or if the server is located far away from the user; • Browser optimization: ss users interact with a web application, their browser can optimize performance by preloading resources, prioritizing critical rendering path, or running faster interpretation of JavaScript, which can make subsequent runs of the application faster.
In terms of speed, we can see that implementations that use server push approach tend to perform better than those using client pull. Among all implementations, WebSocket based messaging showed the best results. On the other hand, short polling shows the worst results by far – it can be influenced by the fact that this approach uses a fixed delay in between requests.
Good speed in real-world instant messaging apps provides several advantages, including: • Quick communication: a fast instant messaging app allows users to send and receive messages quickly, which can be beneficial in time-sensitive situations where quick responses are necessary; • Increased productivity: faster messaging speeds can increase productivity as users can communicate more efficiently and get more work done in a shorter amount of time; • Better user experience: a speedy app can provide a better user experience as it reduces waiting times and ensures that messages are delivered and received without delay; • Improved engagement: fast messaging can encourage users to engage more frequently with the app as they are more likely to respond to messages quickly and keep the conversation going; • Reduced frustration: slow messaging speeds can be frustrating for users, leading to a negative experience with the app. A fast messaging app reduces the likelihood of frustration and improves overall satisfaction with the app.
Overall, a fast messaging app provides several benefits that can enhance user experience, improve productivity, and increase engagement with the app.
Aside from speed, there is another factor we didn’t consider during the experiment run that makes client pull implementations lose in comparison to server push ones. Both short and long polling send a huge number of requests per minute, which in long term affects applications’ performance, overuses resources and puts additional load on server.
Based on the results of the experiment, we can conclude that the optimal instant messaging implementation in terms of speed is WebSocket. However, one should keep in mind other comparison criteria that was mentioned in this paper but wasn’t included in the experiment, such as security and difficulty of development. Those can be additionally measured and investigated further for WebSocket approach, as well as its runner up server-sent events, to verify if the WebSocket based messaging is indeed the best option to go with.
In conclusion, this paper provides readers with an introduction of four different approaches to implementing instant messaging web systems. It gives us a description of what instant messaging is and what advantages it has in comparison with other forms of online communication.
The study presents main approaches to implementing chat systems, describes the principals on which they work, points out similarities and differences between them. Aside from that, the paper selects measurable criteria based on which these methods can be compared and provides justifications for using each of these parameters. The key factors selected for comparison were: • Speed; • Security; • Difficulty of development.
This paper proposes approaches to measure each of these factors, suggests criteria and high-level formulas that can be used for calculating a numeric value of each factor.
Afterwards, an experiment was deducted to measure speed score of each implementation in different testing environments using the same use case. As a result, the WebSocket approach was named an overall best solution speed-wise. However, it is recommended to conduct additional research outside of this paper using the remaining criteria to verify the results.
The key takeaways are: • Server push implementations tend to have higher speed than client pull ones; • Client pull implementations might potentially overload the system by sending too many requests for updates; • WebSocket approach tends to perform slightly better than server-sent events, however the difference in numbers is not significant, so additional investigation might be conducted.
The results of this research can be used when deciding on which approach to use when developing a new instant messaging application, as well as get a general introduction in existing implementations and their main differences.
Furthermore, the research described in this paper can be continued using suggested approaches to specify new key factors and conduct comparison using them. The proposed formulas can be supplemented with additional criteria and weight factors. The results might be used in web application development cycle, as well as expanded to other types of applications, i.e. mobile or desktop ones.