Etude de performance des syst`emes de decouverte de ressources

The Desktop Grid offers solutions to overcome several challenges and to answer increasingly needs of scientific computing. This technology consists mainly in exploiting PC resources, geographically dispersed, to treat time consuming applications and/or important storage capacity requiring applications. However, as resources number increases, the need for scalability, self-organisation, dynamic reconfiguration, decentralization and performance becomes more and more essential. In this context, this paper evaluates the scalability and performance of P2P tools for registering and discovering services (Publish/Subscribe systems). Three protocols are used in this purpose: Bonjour, Avahi and Pastry. We have studied the behaviour of these protocols related to two criteria: the elapsed time for registrations services and the needed time to discover new services.

💡 Research Summary

The paper investigates the scalability and performance of three peer‑to‑peer (P2P) service discovery protocols—Bonjour, Avahi, and Pastry—in the context of Desktop Grids, which harness geographically dispersed PCs to provide large‑scale computational and storage resources. Recognizing that centralized registries such as Globus MDS‑2 suffer from single points of failure and limited adaptability, the authors evaluate decentralized alternatives that could underpin a future middleware for a fully distributed Desktop Grid.

Experimental Platform
All experiments were conducted on the French Grid’5000 testbed, specifically on the Orsay site where more than 300 AMD Opteron machines are interconnected via a 1 Gbps LAN. Each physical node was turned into a “service” that could be registered and later discovered by a client program (the “browser”). The authors measured two key metrics: (1) the elapsed time from the moment a node initiates registration until the service is considered registered, and (2) the time required for the browser to detect a newly registered service. Both sequential registrations (with a configurable delay δ between successive requests) and simultaneous registrations (all nodes request at once) were examined, allowing the study of how network load influences latency.

Protocol Overviews

• Bonjour (Apple’s ZeroConf implementation) relies on link‑local IP address allocation, ARP probing for address uniqueness, and multicast DNS (mDNS) combined with DNS‑Based Service Discovery (DNS‑SD) to advertise services.
• Avahi is the Linux counterpart of ZeroConf, also using mDNS/DNS‑SD but communicating with applications via D‑Bus. Service publication is performed by sending multicast packets to all peers.
• Pastry is a structured P2P overlay that builds a distributed hash table (DHT). Nodes obtain a unique identifier, maintain routing tables and leaf sets, and route messages toward the node whose identifier is numerically closest to a given key. Service registration translates into inserting a key‑value pair into the DHT, while discovery requires traversing several routing hops.

Results – Registration Time
Bonjour: In simultaneous registration tests up to 308 nodes, the elapsed time ranged from 1 017 ms to 2 307 ms, with the majority of nodes completing registration within a narrow 1 015 ms–1 030 ms window. Sequential tests showed a linear increase proportional to the inter‑request delay δ, but individual registration latency remained comparable to the simultaneous case. The authors note that ARP cache size (≈1 040 entries) comfortably exceeds the number of services, so cache contention does not explain the observed variance.

Avahi: Simultaneous registration times fell between 700 ms and 1 100 ms, slightly better on average than Bonjour. Sequential registration exhibited a bit more variability, likely due to the additional D‑Bus messaging overhead. Nevertheless, the overall latency stayed under 1.2 seconds even at full scale, confirming that the multicast‑based approach scales well to a few hundred nodes.

Pastry: Registration required roughly 1.5 – 2 seconds on average, noticeably higher than the ZeroConf solutions. The extra delay stems from the need to locate the appropriate DHT node, update routing tables, and propagate the key‑value pair across multiple hops. While Pastry’s logarithmic routing guarantees scalability in theory, the practical cost of bootstrap and table maintenance becomes significant at the 300‑node scale examined.

Results – Discovery Time
For both Bonjour and Avahi, the time between a service’s successful registration and its detection by the browser was on the order of a few hundred milliseconds, largely independent of the total number of nodes. Pastry’s discovery latency was consistently larger because the client must perform a DHT lookup that traverses several intermediate nodes. The paper does not provide exact numbers for Pastry discovery, but the trend mirrors the registration findings.

Scalability Discussion
ZeroConf protocols rely on multicast traffic; thus, as the number of participants grows beyond a few hundred, network congestion could degrade performance. However, within the tested range (up to ~300 nodes), multicast traffic remained manageable, and both Bonjour and Avahi delivered stable, low‑latency service registration and discovery. Pastry, by contrast, offers theoretical scalability to thousands of nodes due to its structured overlay, but the initial bootstrap phase and continuous routing‑table synchronization impose overhead that may outweigh its benefits in smaller clusters.

Conclusions and Recommendations
The authors conclude that for Desktop Grid deployments of a few hundred nodes, a ZeroConf‑based solution (Bonjour or Avahi) is preferable: it is easier to integrate, requires no special configuration, and provides sub‑second registration and discovery times. For much larger infrastructures where thousands of nodes must be managed, a DHT‑based system like Pastry could be considered, provided that additional mechanisms are implemented to mitigate bootstrap costs and to handle the higher per‑operation latency. The study supplies quantitative evidence to guide middleware architects in selecting the most appropriate service discovery protocol for their target scale and performance requirements.