Distributed System

Introduction:In today’s networked world, computers rarely work in isolation. They collaborate with each other for the purpose of communication, processing, data transfer, storage etc., When systems work in this collaborative fashion with other systems that are geographically scattered over wide distance, it is commonly known as a distributed system[1]. A field of computer science that discusses distributed systems is called distributed computing.

Distributed computing is a method of computer processing in which different parts of a program run simultaneously on two or more computers that are communicating with each other over a network. Distributed computing is a type of segmented or parallel computing, but the latter term is most commonly used to refer to processing in which different parts of a program run simultaneously on two or more processors that are part of the same computer.

While both types of processing require that a program be segmented—divided into sections that can run simultaneously. Distributed computing also requires that the division of the program take into account the different environments on which the different sections of the program will be running. For example, two computers are likely to have different file systems and different hardware components.

An example of distributed computing is BOINC, a framework in which large problems can be divided into many small problems which are distributed to many computers. Later, the small results are reassembled into a larger solution.

Distributed computing is a natural result of using networks to enable computers to communicate efficiently. But distributed computing is distinct from computer networking or fragmented computing. The latter refers to two or more computers interacting with each other, but not, typically, sharing the processing of a single program.

The World Wide Web is an example of a network, but not an example of distributed computing. There are numerous technologies and standards used to construct distributed computations, including some which are specially designed and optimized for that purpose, such as Remote Procedure Calls (RPC) or Remote Method Invocation (RMI) or .NET Remoting.

This paper presents a basic review on various security issues and challenges which come across with the use of distributed computing that arise from the fact that many modern distributed systems will be part of our pervasive computing environment. Distributed systems have been built with the objective of attaining the following:

 Transparency

 Openness

 Reliability

 Performance

 Scalability

In order to achieve the above objectives, security of the system must be given adequate attention as it is one of the fundamental issues in distributed system[2]

1. Security Issues:-In order that the users can trust the system and rely on it, the various resources of a computer system must be protected against destruction and unauthorized access. Enforcing security in a distributed system is more difficult than in a centralized system because of the lack of a single point of control and the use of insecure networks for data communication. Security for information resources in distributed system have 3 components : 1.1 1.1 Confidentiality : protection against disclosure to unauthorized individuals. 1.2 1.2 Integrity : protection against alteration/corruption

1.3 Availability : protection against interference with the means to access the resources.

1.1 Confidentiality : Confidentiality prevents sensitive information from reaching the wrong people, while making sure that the right people can in fact get it. A good example is an account number or routing number when banking online. Data encryption is a common method of ensuring confidentiality. User IDs and passwords constitute a standard procedure; two-factor authentication is becoming the norm and biometric verification is an option as well. In addition, users can take precautions to minimize the number of places where the information appears, and the number of times it is actually transmitted to complete a required transaction.

1.2 Integrity :Integrity involves maintaining the consistency, accuracy, and trustworthiness of data over its entire life cycle. Data must not be changed in transit, and steps must be taken to ensure that data cannot be altered by unauthorized people (for example, in a breach of confidentiality). In addition, some means must be in place to detect any changes in data that might occur as a result of non-human-caused events such as an electromagnetic pulse (EMP) or server crash. If an unexpected change occurs, a backup copy must be available to restore the affected data to its correct state.

1.3 Availability :Availability is best ensured by rigorously maintaining all hardware, performing hardware repairs immediately when needed, providing a certain measure of redundancy and failover, providing adequate communications bandwidth and preventing the occurrence of bottlenecks, implementing emergency backup power systems, keeping current with all necessary system upgrades, and guarding against malicious actions such as denial-of-service (DoS) attacks. 2. Challenges:-

Let us look at a few challenges for large-scale distributed systems for which it can be argued that they have never been, and perhaps will never be, solved to our full satisfaction. In the following, we address just a few that we believe are very important, but there are obviously many more, often specific problems.

2.1 Distribution transparencyDistribution transparency reflects the extent to which a system appears as a whole, rather than being a collection of independent components. In other words: a high degree of transparency will let the system appear to be coherent to its users. The extreme case is when a single-system view can be offered, virtually indiscernible from a nondistributed system.

The problem with striving for distribution transparency in very large systems is that performance will degrade to unacceptable levels[3]. The cause is obvious: being networked, we need to face failures and their recoveries that can never be fully masked. In addition, network latencies have a natural lower bound that becomes noticeable when dealing with long-haul connections.

These performance problems can be partly tackled through replication, by which components are copied and placed close to where they are needed, but as soon as readto- update ratios decrease, replication may actually lead to a scale-down of the system if consistency is needed (see also [4]). Moreover, the CAP principle tells us that we simply cannot combine consistency and availability in the presence of network partitions [5].

There is no simple solution to achieving distribution transparency, and we will have to continue to look for application-specific solutions to achieve acceptable transparency. The last word has not been said, and the main challenge remains to discover what is actually acceptable to users.

2.2 Heterogeneity of components

2.3 Scalability2.4 Failure Handling2.5 Concurrency


  1. Implementation of Security in Distributed Systems – A Comparative Study in International Journal of Computer Information Systems, Vol. 2, No. 2, 2011 , Mohamed Firdhous Faculty of Information Technology, University of Moratuwa, Moratuwa, Sri Lanka. [email protected] 2. Zhidong Shen and Xiaoping Wu, “The Protection for Private Keys in Distributed Computing System Enabled by Trusted Computing Platform,” in International Conference On Computer Design And Appliations (ICCDA 2010), Qinhuangdao, Hebei, China, 2010, pp. 576-580.

3.“Challenges in very large distributed systems” in J Internet Serv Appl DOI 10.1007/s13174-011-0043-x ,Maarten van Steen,Guillaume Pierre,Spyros Voulgaris November 2011 4. van Steen M, Pierre G (2010) Replicating for performance: case studies. In: Charron-Bost B, Pedone F, Schiper A (eds) Replication, theory and practice. Lecture notes in computer science,vol 5959. Springer, Berlin, pp 73–89. Chapter 5 5.Gilbert S, Lynch N (2002) Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News 33(2):51–59