On two modifications of E-r/E-s/1/m queuing system subject to disasters

The paper deals with modelling a finite single-server queuing system with the server subject to disasters. Inter-arrival times and service times are assumed to follow the Erlang distribution defined by the shape parameter r or s and the scale parameter rλ or sμ respectively. We consider two modifications of the model − server failures are supposed to be operate-independent or operate-dependent. Server failures which have the character of so-called disasters cause interruption of customer service, emptying the system and balking incoming customers when the server is down. We assume that random variables relevant to server failures and repairs are exponentially distributed. The constructed mathematical model is solved using Matlab to obtain steady-state probabilities which we need to compute the performance measures. At the conclusion of the paper some results of executed experiments are shown.Web of Science12215814

A cloud queuing service with strong consistency and high availability,”

Message queues are widely used to connect loosely coupled components to form large-scale, highly distributed, and fault-tolerant applications. A number of vendors currently provide cloud-based queuing services that are designed to be elastic, scalable, and easy to use. However, unlike enterprise queuing systems, which provide strong queuing consistency and are suitable for many traditional enterprise workloads, these cloud-based queuing services offer reduced queuing consistency. They can deliver messages without loss, but they may deliver messages out of order or with duplications. This paper presents SilverDove Queuing Service (SDQS), a scalable cloud-based queuing service with stronger consistency than existing cloud-based queuing services. SDQS delivers messages without losses or duplications and provides in-order message delivery as an option. Built on top of IBM WebSphere A eXtreme Scale, i.e., an elastic in-memory object grid system, SDQS can be easily scaled up and down to accommodate a wide range of workloads. SDQS is able to provide high availability with either the no-order or the in-order message delivery option. We have performed a preliminary evaluation of SDQS with up to 70 nodes on a compute cloud platform, verifying its consistency offerings and providing insights into the tradeoff between performance and consistency. Introduction As computing reaches every corner of people's daily lives, including business informatics, personal entertainment, and real-world event sensing, the scale and complexity of software systems grow exponentially. Coming with this trend is the critical challenge to provide reliable, efficient, and flexible mechanisms for large-scale distributed computing components or applications to communicate with one another. One of the most widely adopted interapplication communication patterns is asynchronous message exchanges through message queues. A message queue decouples the two communicating parties from each other. It provides temporary storage when the destination application is busy or suffering from poor connectivity. It reduces the involvement of application developers with the complexity of handling the communication mechanisms. It also simplifies the development, deployment, and management of complex distributed applications that span multiple heterogeneous operating systems and network protocols. Exemplary applications that can benefit from message queues include workload dispatching/load balancing, MapReduce [1]-like pipelined processing, distributed workflow management, and information aggregation/dissemination, to name just a few. In addition to being used for asynchronous message exchange, message queues may also be used to support synchronous request-response communication patterns that are common in traditional enterprise application integration. A typical usage scenario is the supporting of Simple Object Access Protocol over Java** Message Service. With the advent of advanced virtualization technology, many enterprises are adopting cloud computing to reduce their capital and operational expenditure. Along with the trend comes the imperative to provide message queuing (MQ) as a common cloud service that can be consumed by Copyright 2011 by International Business Machines Corporation. Copying in printed form for private use is permitted without payment of royalty provided that (1) each reproduction is done without alteration and (2) the Journal reference and IBM copyright notice are included on the first page. The title and abstract, but no other portions, of this paper may be copied by any means or distributed royalty free without further permission by computer-based and other information-service systems. Permission to republish any other portion of this paper must be obtained from the Editor. multiple tenant organizations and applications. In order to fully realize the benefit of cloud computing and to accommodate the rapidly growing and highly dynamic workloads from today's data-intensive applications, a cloud-based MQ service should be highly reliable and highly elastic while providing good performance. A common approach adopted by many cloud-based queuing service providers focuses on lower cost, elasticity, and availability as the main design objectives while relaxing queuing semantics. Examples include Amazon's Simple Queue Service (SQS) On the other hand, traditional enterprise-class MQ systems, such as IBM WebSphere* MQ and Microsoft MSMQ, and Apache ActiveMQ**, offer excellent system performance and various other desirable features such as exactly once delivery, FIFO message ordering, and distributed transaction support. These messaging middlewares play an important role in applications that cannot tolerate message duplication or require strict FIFO delivery order. Many financial applications fall into this category. To enable these types of applications to be eventually migrated to a cloud environment and thus realize the cloud computing benefits, it is important to provide a highly available and scalable queuing service with strict queuing consistency. We note that with the strict queuing consistency offerings comes the inevitable tradeoffs that one would have to make in other metrics, such as performance or availability. Therefore, it is also highly desirable for a queuing service to provide applications with options for selecting only the necessary queuing consistency level so that the service can maximize the level of other nonfunctional qualities. Toward this end, this paper presents the design and evaluation of a cloud-based queuing service code-named SilverDove Queuing Service (SDQS). SDQS is built on top of IBM WebSphere eXtreme Scale [4], which is an elastic in-memory data grid system. Although WebSphere eXtreme Scale provides high storage consistency, it is a challenging task to provide high queuing consistency on top of it. SDQS overcomes the challenge by using a queue indexing approach and a visibility-timeout mechanism. With no failures in network transport and client applications, SDQS is able to provide exactly once message delivery, i.e., no loss or duplication, while offering two kinds of message order options to end users, which can be selected when establishing queues in the system. This represents stronger consistency than existing cloud-based offerings, approaching that of a traditional enterprise queuing product. Additionally, SDQS provides high availability and elasticity. We point out that end-to-end strong consistencies under all failure conditions are not currently provided by SDQS. Please refer to the ensuing sections for more detailed discussions. The main contribution of this paper is twofold. First, it presents a cloud-based scalable queuing service, which to our best knowledge is the first in its kind capable of providing exactly once message delivery in FIFO order. Second, through evaluation, it quantitatively compares SDQS to other representative queuing services and validates its queuing consistency and high availability. We note that SDQS is a research prototype designed to investigate the possibility of providing strong queuing consistency with high availability. It does not represent the official product plan or roadmap of IBM in the area of cloud-based messaging. The remainder of this paper is organized as follows. Background knowledge and related work are introduced in the next section, which is followed by a description of the system architecture and design. The following section provides the details of the implementation, evaluation methodology, and results. The final section concludes this paper. Background and related wor

Managing Network Delay for Browser Multiplayer Games

Latency is one of the key performance elements affecting the quality of experience (QoE) in computer games. Latency in the context of games can be defined as the time between the user input and the result on the screen. In order for the QoE to be satisfactory the game needs to be able to react fast enough to player input. In networked multiplayer games, latency is composed of network delay and local delays. Some major sources of network delay are queuing delay and head-of-line (HOL) blocking delay. Network delay in the Internet can be even in the order of seconds. In this thesis we discuss what feasible networking solutions exist for browser multiplayer games. We conduct a literature study to analyze the Differentiated Services architecture, some salient Active Queue Management (AQM) algorithms (RED, PIE, CoDel and FQ-CoDel), the Explicit Congestion Notification (ECN) concept and network protocols for web browser (WebSocket, QUIC and WebRTC). RED, PIE and CoDel as single-queue implementations would be sub-optimal for providing low latency to game traffic. FQ-CoDel is a multi-queue AQM and provides flow separation that is able to prevent queue-building bulk transfers from notably hampering latency-sensitive flows. WebRTC Data-Channel seems promising for games since it can be used for sending arbitrary application data and it can avoid HOL blocking. None of the network protocols, however, provide completely satisfactory support for the transport needs of multiplayer games: WebRTC is not designed for client-server connections, QUIC is not designed for traffic patterns typical for multiplayer games and WebSocket would require parallel connections to mitigate the effects of HOL blocking