Capacity Management: Transforming P2P Overlays for the Mobile Era

TL;DR

The classic "flat" P2P architecture, where every node is treated as an equal, is failing in the world of mobile-first connectivity. This paper proposes a Capacity Management Protocol for the LibreSocial OSN. By identifying and isolating mobile ("weak") nodes from heavy-duty tasks like data replication and routing, the network gains massive stability even when 75% of its participants are resource-constrained devices.

The Problem: The Myth of Peer Equality

During the early days of Napster and BitTorrent, P2P nodes were mostly stable PCs. Today, the landscape is dominated by smartphones on metered, intermittent mobile connections.

Current Distributed Hash Tables (DHTs) suffer from:

1. Churn: Mobile nodes vanish and reappear, forcing constant, expensive network re-organization.
2. Resource Exhaustion: Asking a smartphone to replicate gigabytes of social media data kills battery and data plans.
3. Routing Latency: Weak nodes slow down lookup queries for the entire network.

Methodology: Tiered P2P Hierarchy

The core insight is simple but powerful: Acknowledge the inequality. The authors move away from a flat DHT to a tiered role system governed by Algorithm 1 (Classification) and Algorithm 3 (Capacity Handling).

1. Classification (isWeak)

Nodes perform a self-check based on:

• Device Type: PC (Strong) vs. Mobile (Weak).
• Capacity Thresholds: Memory, Storage, and Battery levels.

2. Selective Role Assignment

• Strong Nodes: Handle the full DHT routing table and act as the primary "Replica Set" for data storage.
• Weak Nodes: Act as "clients." They are excluded from routing tables of distant nodes and do not store replicas. They maintain only a Leafset (a list of immediate neighbors) to send/receive their own data.

Figure 1: The LibreSocial architecture with the integrated Capacity Management module.

Experimental Battle-test

The authors tested the protocol on an HPC cluster with 200 LibreSocial instances. They varied the ratio of "strong" to "weak" nodes (1/2, 1/3, and 1/4).

Key Findings:

• Stability: Even with only 25% strong nodes (1/4 ratio), the network did not collapse.
• Routing Performance: Lookup times remained impressively low (under 10ms) regardless of the node ratio, proving that keeping weak nodes out of the routing path prevents performance degradation.
• Storage Trade-offs: In the 1/4 strong-node scenario, storage and retrieval times spiked. This is the "cost" of stability—with fewer strong shoulders to carry the load, those nodes become bottlenecks during heavy write operations (e.g., uploading photo albums).

Figure 2: Analysis of Node Count and Lookup Times across different capacity ratios.

Critical Insight & Analysis

The success of this protocol lies in its Inductive Bias toward stability over pure decentralization. By concentrating the "backbone" of the OSN on strong nodes, the authors create a "Virtual Infrastructure" within a P2P environment.

Pros:

• Protects mobile users' data plans and battery.
• Drastically reduces network maintenance traffic caused by churn.

Cons/Limitations:

• Centralization Risk: If the number of strong nodes drops too low, the network becomes effectively centralized and prone to targeted attacks.
• Latency: As shown in the 1/4 test, while the network stays up, the user experience (UX) for data-heavy tasks degrades significantly.

Conclusion

This work provides a pragmatic blueprint for building P2P applications that actually work on modern hardware. By treating heterogeneity as a feature rather than a bug, LibreSocial demonstrates that decentralized social networks can survive the volatility of the mobile web. Future work should likely focus on Incentivization—how do we encourage users to act as "Strong Nodes" if they bear all the storage burdens?