The reliable communication in a distributed application when the application is set in a client-server style
An application is basically defined as a program which is tailor-made to perform a specified business task using several applications in a computer system. Examples of “applications include word processors and payroll application” (Laudon 2010). Applications exchange information through operating systems. According to Girdhar (2013), the work of a distributed system is to provide availability or continuity, even if faults occur within the system. This may be achieved through resources and creating redundancies within the network. The duration of any application is reduced by executing it in parallel form in the computer systems. Distributed systems are interconnected with a Local Area Network (LAN).
In LAN, the terms ‘server’ and ‘client’ are common. The server is and defined as a process or processes whose main role is to manage and implement resources or services. On the other hand, the term client refers to a process or processes which access the resources that are implemented by the server. What happens in a client-server communication style is that, a client communicates a request to use the resources to the server, while at the same time the outcome of the request is communicated to the client by the server in the form of a response (Laudon 2010).
This request-response form of interaction is the basis for the client-server communication style. The client-server communication is through the exchange of messages. A distributed system spreads information to several computers tied up in a network for processing. This, in turn, enhances efficient use of resources while distributing access to the end-user. Breaking down the application into smaller components parts for distribution purposes is much more complex than implementing the same application in a single system (Jessup and Valacich, 2008).
According to Laudon (2010), the client-server model emerged in the 1980s. This model is a two-way execution of programs. As such, it makes the request to access the information or services, and also gives the outcomes of these requests inform of responses concurrently. This illustrates the distributed application. The programs for making requests (clients) always require simple interfaces for facilitating these requests. Client programs, therefore, do not process information.
Ideally, they can be designed to run on non-powerful computers such as personal computers. Unlike client programs, server programs must run on powerful and faster systems like workstations, which mostly access a large pool of database which stores corporate information. Due to the heterogeneity of computing environments within the corporate, the client-server model fits well. The model can also provide efficient access to shared resources while safeguarding the information at the same time.
There are three main approaches to designing distributed applications. These are remote call procedure (RPC), a standard-based approach to the computing environment, object request brokering approach, which is an industry-based approach, and the message queuing approach, a popularized approach by the leading vendors (Jessup and Valacich, 2008). In a distributed system, failures and faults occur in some of the components. However, the distributed system is constructed and designed in such a way that these failures are minimized in order to mitigate their impact on the overall performance of a system. It is important to note that the distributed system continues its operations even when such failures occur. These failures are repaired as they occur while the system carries on. There is some kind of resilience that makes the system operate even in the presence of such faults.
For a distributed system to be dependable even when faults occur, it must have the following features (Laudon 2010). It has to be available, maintainable, safe and reliable. Availability means that a system is ready to perform its functions to the end-user, with a probability of operating correctly. On the other hand, maintainability refers to the fact that a system can be repaired with ease when faults occur. Safety means that the effects of failures are not detrimental or disastrous to the entire system when they occur. Finally, reliability means that a system can run continuously without interruptions or failures of any kind.
Failures within a system are classified as crash, omission, timing, response and arbitrary failures. While a crash failure halts operations, an omission failure hinders response to the incoming messages or requests. On the other hand, while a timing failure makes a system delay in responses, a response failure results in incorrect responses. Finally, an arbitrary failure renders the system to introduce failures at arbitrary intervals (Laudon, 2010).
In a distributed-based application, a client-server model is imperative and efficient in creating reliable communication within the distributed systems. When creating a reliable client-server communication, much emphasis is laid to the failures envisaged to occur within the system. These emphases are in terms of masking omission and crash failures. Laudon (2010) highlights the main strategies employed for reliable communication in a distributed application that is set in a client-server style. One of the strategies is point-to-point communication. As such, in a distributed system, reliable point-to-point communication is constructed by the use of reliable transport protocols which mask omissions.
These omissions mostly occur as lost messages—the reliable transport protocol masks these omissions through retransmissions and acknowledgements, which are then hidden to the client. An example of a reliable transport protocol is the TCP protocol. It is important to note that only the omission failures are masked by the reliable transport protocol. In case of a crash omission the end-user or simply the client is notified that a crash has occurred within the system, such failure is rectified automatically when the system sends a new connection by resending a new request. The other strategy is witnessed when remote procedures calls (RPCs) are made when failures occur.
The essence of using RPCs facilities is to hide communication by making remote call procedures facilities appear like local ones. This strategy works well only when the functionality between client and server is perfect. RPC facilities do not function when errors occur within the system, and this makes it difficult to mask the local calls. Some of these errors occur when the client does not locate the server, when crashes occur within the system and when the messages are lost. To resolve this, the system automatically evolves through the installation of a new interface that generates new stubs which are then utilized. The system raises exceptions to the client when faced with such errors. Therefore, maintaining client-server interaction is the key to reliable communication in a distributed application.
How to establish a reliable group communication in a distributed application
Currently, most operating systems which have distributed systems use remote procedure calls. The essence of this is to conceal the message being passed and make the communication process appear as if it is a remote procedure call (Jessup and Valacich, 2008). Resilience within the process is important. However, creating reliable multicasts within the system is more important than process resilience since reliable multicasts ensure that information or messages reach out to all members of the process group. Reliable group communication is enhanced by constructing basic, reliable multicasting schemes (Wedd and Martens, 2002).
These schemes are, on the contrary to the schemes that adopt point-to-point communication. Multicasting enables efficiency within the network bandwidth. The process of multicasting is considered to be reliable when all non-faulty members of a group receive the message. To foresee this, a kind of agreement is reached in order to gain insights relating to the appearance of the group. Within the group, there is no requirement that the messages should be received in the same order by the group members. This makes reliable multicasting schemes easy to implement. There is a major drawback to reliable multicasting schemes; these schemes cannot support many receivers.
When there are large numbers of receivers, a scenario known as feedback implosion arises, this means that there are numerous feedback acknowledgements. Feedback implosion is resolved by ensuring that the receivers acknowledge reception of messages. The concept of feedback suppression is also applied in order to ensure that there is a reduction in the number of messages that are sent back to the sender. It is also important to note that when the feedback is multicast other groups are able to suppress their feedback. Feedback suppression has been able to operate efficiently, and it is widely used in internet applications that are collaborative.
Unlike reliable multicasts schemes, atomic multicasts schemes create a guarantee that the messages are delivered to all members of a group or none at all. In atomic multicasts, there is the requirement that all messages be delivered in the same order to all the processes (Laudon, 2010). Atomicity creates the atomic multicast problem which is manifested in the requirement that all messages be delivered in the same order, and to all the groups. A distributed system enables the construction of groups through which reliable messages can be sent. In atomic multicasts, it is assumed that a protocol for replicating database is used. When updates are performed, a replica may crash meaning that execution on the crashed replica is not foreseen, this isn’t detrimental since the execution of the performed updates is done on the non-crashed replicas (Jessup and Valacich, 2008).
The updates for the crashed replica are purely lost, even if the replica recovers. With atomic multicasts, it is important to note that when one replica crashes, the other replicas will only accept execution of updates through an agreement that one replica has crashed, and it is not operational since its full recovery. A recovering replica is allowed to join the process groups only after membership registration. Atomic multicasting also enhances reconciliation between the replicas, when the crashed replicas recovers and rejoins the process group once again. Therefore, within a system, multicasting schemes are adopted in order to establish reliable group communication in distributed applications. The schemes ensure that all processes within the group to either receive or not receive the intended messages or updates within the system for subsequent execution.
References
Girdhar, J (2013). Management Information Systems. New Delhi: Oxford University Press. Web.
Jessup, L., & Valacich, S. (2008). Information Systems Today (3rd edition.). London: Idea Group Publishing. Web.
Laudon, K. (2010). Management information systems: Managing the digital firm. (11th edition). Upper Saddle River, NJ: Pearson Prentice Hall. Web.
Wedd. J, & Martens, P. (2002). Strategic Planning for Information System. West Sussex. John Wiley & Sons Ltd. Web.