P2P Middleware
From P2P Wiki
Contents |
Definition
The P2P networks can be briefly defined as logic networks constructed upon Internet in which users collaborate in a decentralized way in their maintenance and operation. At the present time, new research lines have arisen in order to palliate the deficiencies of traditional p2p networks as Emule[], Kazaa[] and Gnutella[].
Concretely, structured P2P networks have taken the lead and they offer services of information transmission to world-wide scale, such as the distributed hash tables (DHT). Moreover, it is not usually easy to develop a P2P application from scratch, since not so many wide-area middleware solutions exist. As a consequence, developers have to waste their time reinventing the wheel by building common services. Such basic services include fault tolerance, data replication and caching, security, application-level multicast, along with many others.
In this setting, several middleware platforms are appearing that benefit of the novel services offered by the overlay networks. Prominent examples of the literature are offered by the american project IRIS [?] with platforms such as OpenDHT [1] and the i3 Indirection Infrastructure [2]. These infrastructures, because of their optimized routing systems, their information locating systems, and novel network locality services such as anycast or multicast promise to be a key middleware to develop large scale applications. In fact, they have already developed on top of DHTs, systems like the DNS, Usenet, instant messaging, data distribution systems or distributed file systems. Unfortunately, they still suffer from important limitations that restrict their widespread adoption.
Wide Area Middleware
Over the years, the Internet has been growing steadily in its number of users and nowadays its ubiquitous nature is well-assumed by everybody. Network bandwidth has increased considerably and the emergence of many successful wide-area applications has made it more and more popular. Apart from network bandwidth itself, computers have greater overall capacity and their resource sharing capabilities are improving day by day. When creating global-scale Internet-based distributed applications, developers repeatedly face the same implementation issues: object location, replication, mobility, caching, etc. Middleware plays a key role in addressing these challenges because it provides a common higher-level interface for application programmers and hides the complexity of myriad underlying networks and platforms. Middleware systems have a long tradition in centralized client–server environments, but there are very few globally scalable middleware solutions. The distributed object-oriented middleware frameworks that get the most attention are those that model messaging as method calls. These systems are often called Remote Procedure Call (RPC) [3] systems. The major benefit of these systems is that they make remote procedure (or method) calls appear to be local procedure calls (LPCs). This is a powerful abstraction that considerably simplifies the development of remote applications. Mature examples of this middleware are the Common Object Request Broker Architecture (CORBA) [4] or the Java Remote Method Invocation (RMI) [5].
Message Oriented Middleware
Message Oriented Middleware (MOM) has recently received considerable attention because of its decoupled nature, which nicely solves asynchronous one-to-many interactions and highly dynamic distributed environments. Unlike RPCs, MOMs do not model messages as method calls; instead, they model them as events in an event delivery system. Clients send (produce) and receive (consume) events, or messages, and producers and consumers do not explicitly know each other. All applicationscommunicate directly with each other using the MOM. Messages generated by applications are meaningful only to other clients, because the MOM itself is only a message router. Nevertheless, distributed object-oriented frameworks and MOMs are still almost isolated worlds that do not fully benefit from each other‘s unique advantages and concepts. Architecturally, both middleware approaches are mostly built on top of centralized client/server models, and this is proven to work well in local-area or even metropolitan- area environments. However in wide-area settings, these platforms clearly suffer from scalability problems, although these can be solved by forming cluster topologies among servers. This option may not be economically viable in all cases. The current trend is to head towards decentralized models which benefit more from the computing at the edge paradigm, where resources available from any computer in the network can be used and are normally made available to their members. Therefore, there is a need for a middleware platform that can be used to develop worldwide oriented distributed applications. This middleware must be scalable, provide fault tolerance, be able to adapt to continuous node joins and leaves in the network, provide high availablity guarantees, and be a good use maker for the computational resources available on the edges of the Internet. Do any of the available middleware systems comply with all these requirements? The answer is mainly no. Existing middleware approaches for wide-area scale applications do not provide all of these services. Therefore, a great deal of time must be invested in providing such guarantees first. Sometimes, it is very difficult or practically impossible to comply with these requirements. Therefore, we propose that a middleware framework be created for developing distributed applications that run on top of very dynamic and changing environments. This approach fulfills our requirements, thus allowing developers to concentrate on the application itself, and not on the underlying common services.
Wide Area Persistance Systems
Another of the pillars of our proposed wide-area middleware solution is the need for a persistence service. This service should allow data to be eficiently stored and looked up in a wide-area environment. There has been a long history of research in the area of distributed file systems and storage. Some of these wide-area persistence systems are shown next:
Requirements
The creation of a wide-area middleware platform is a complex challenge, and requires a set of basic features, which means that a variety of problems must be overcome. We need to fulfil the following requirements:
- Scalability. Any wide-area middleware needs to be scalable, so that it can support applications which may require global-scale concurrent access and utilization. There are a wide variety of client-server middleware approaches. However, the platforms suffer from scalability problems, since the server itself becomes the bottleneck of the whole architecture. One solution to this came in the form of the clustering or federation of servers. Following a decentralization pattern, servers are made redundant so when one becomes unavailable, another one can take its place. There are several variants of this system, where requests can be redirected to one server or another, depending on their load, or simply in a sequential order. Nevertheless, this redundant server alternative is normally expensive to achieve and maintain.
- Fault tolerance. We require our wide-area distributed applications to be as fault tolerant as possible. This feature allows graceful recovery from errors, and it is aimed to be provided by the middleware layer in a transparent way. Therefore, we need to assure that all possible resources can be located at all times. Our network routing layer should be aware of possible failures, and should be smart enough to avoid these failures by re-routing messages appropriately.
- High availability. This requirement is a consequence of fault tolerance. High availability refers to the fact that access to any resource must be guaranteed at all times. Therefore, we need to have a transparent mechanism that can guarantee access to resources at any time. The idea of high availability usually comes in the form of data replication. So if there is some redundancy, the guarantee of high availability improves.
Therefore, we should provide some redundancy or replication of resources so as to permit high availability. In order for this redundancy to be kept synchronized, we need efficient state change notifications. Since propagating state from one object to each of its replicas is going to be a usual task, we require a group communication service. This service should use the multicast primitive, which allows notifications to be sent from one source to many targets. Centralized event systems have proven to be a very useful group communication middleware in the design of distributed applications. The distributed information bus (event bus) is responsible for transmitting to subscribers events thrown by producers based on the information contained in these events.
- Load balancing. Load balancing‘s main aim is to distribute processing and communication activity evenly across a computer network so that no single device is overwhelmed. This service is especially important for networks in which it is difficult to predict the number of requests that will be issued to a node, and this is the case of our scenario. Sometimes, a specific resource may be requested by many nodes, swamping the responsible node (the Britney problem). In order to avoid such a problem, load must be evenly distributed to other nodes holding replicas of the resource (linked to the high availability requirement). Even though an efficient group communication service is needed for our middleware if one-to-many notifications are to be propagated, this scenario can be further enriched, and related to the the requirement we are describing. We could think about benefiting from other primitives (if available), like anycast. Anycast allows messages to be delivered to the closest member of a multicast group, where closeness is defined in terms of a particular metric (for example, network proximity). This primitive can be used to construct a load balancing service that our middleware can offer transparently to the upper layers. For example, requests can be directed to a group member and, if it is overwhelmed, re-routed to the closest member, by following an anycast pattern.
- Dynamicity. This feature accounts for the fact that the members of the network do not usually remain constant. The routing substrate must allow for this behaviour. Therefore, it must guarantee that resources are moved from nodes when they leave, and that new responsibilities are assigned to newcoming nodes. Since our middleware targets highly dynamic environments, the routing substrate must provide the necessary primitives to guarantee this feature without losing data.
- Usability and Programming Abstractions. Middleware solutions should never forget their target users, and therefore never underestimate the importance of their own ease-of-use. It is not sufficient for a middleware to just implement all the functionality required for building applications; it should also be easy to use.
Implementing applications should be as easy as possible, and both the middleware and the applications developed should be easy to deploy and manage. It is also important to distinguish which programming abstractions are available to the developer in order to work with the middleware. Categorization may include availability of remote objects or components, object location facilities, group communication primitives, etc.
See also
Wide area middleware systems:
Wide area persistance systems:
References
[1] Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, and Harlan Yu. OpenDHT: A Public DHT Service and Its Uses. Proceedings of ACM SIGCOMM 2005, August 2005.
[2] Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker and Sonesh Surana. Internet Indirection Infrastructure. Proceedings of ACM SIGCOMM, August, 2002.
[3] A. R. Tripathi and T. Noonan, "Design of a Remote Procedure Call System for Object-Oriented Distributed Programming," Software-Practice and Experience, vol. 28(1), pp. 23-47, 1998.
[4] Object Management Group's CORBA Website, available at http://www.omg.org/corba.
[5] Sun Microsystems' Java Remote Method Invocation (Java RMI), available at http://java.sun.com/products/jdk/rmi/.
