Trans-SocialDP: Turning Your Facebook Friends into a Distributed Supercomputer

TL;DR

Trans-SocialDP is a platform that transforms social networks into distributed computing grids. By mining "friendship" data from APIs like Facebook and OpenSocial, it allows everyday users to share idle CPU cycles with people they trust. It moves "volunteer computing" away from giant scientific projects like SETI@home and into the hands of common users who need extra power for multimedia encoding or personal research.

Executive Summary

The untapped potential of idle computing resources in household PCs is astronomical. While Grid and P2P computing have existed for decades, they suffer from a lack of trust and high barriers to entry for non-specialists. Trans-SocialDP bridges this gap by using the social graph as a discovery layer. It leverages existing relationships (friends, groups, communities) to create a "Social Cloud" where computing power is shared as easily as a status update.

Problem & Motivation: The Loneliness of Idle Cycles

Most computers sit idle for the majority of the day. Projects like BOINC successfully harvest these cycles but are generally "top-down"—meaning a large institution creates a project, and you donate to them.

The authors identified two major shortcomings:

1. Lack of User Autonomy: Common users cannot easily set up their own distributed tasks without deep technical expertise.
2. Trust Deficit: In standard P2P networks, you don't know who is running your code or providing the results. By using Social Networks, the "Identity" problem is solved; you share resources with people you already have a connection with, increasing the likelihood of cooperation and legitimate results.

Methodology: The Trans-Social Architecture

The core of the system is split into two functional layers: the Social Interaction Layer and the Local Management Layer.

1. Resource and People Discovery

Instead of a central server, Trans-SocialDP uses Social Network APIs (Graph and REST) to find peers. It searches through:

• Direct Friends: The most trusted tier.
• Friends of Friends (FoF): Expanding the pool while maintaining a degree of separation.
• Common Interest Groups: Leveraging shared goals (e.g., a university research group).

2. The Task Unit: Gridlets

Utilizing the Ginger Middleware, the architecture breaks down "Jobs" into "Gridlets." A Gridlet is a self-contained unit containing the data and the executable arguments.

3. Idle-Time Sensing

To ensure the system doesn't lag the host's computer, it uses the SIGAR library. This allows the platform to monitor CPU and Memory usage in real-time, only accepting Gridlets when the user is not actively using the machine.

Figure 1: The modular architecture of Trans-SocialDP, showing the Messaging, People Discovery, and States Engines.

Experiments & Results

The researchers evaluated the system using a "Mixed Scenario" involving 14 users across Facebook and MySpace. The goal was to process 8 major tasks (Gridlets) with an estimated local execution time of 40 minutes.

Performance Gains

Despite the communication overhead of the Social Network servers (sending messages via "Walls" or "Posts"), the system consistently outperformed local execution.

Figure 2: Total processing time for a Job across different test runs. Test 3 shows a spike due to server-side latency.

Key Findings:

• Speedup: The total processing time decreased across all tests compared to a single-machine execution.
• Multi-Platform Identification: One challenge was identifying the same user across different networks (e.g., User A on Facebook is also User A on MySpace) to avoid sending double tasks to the same hardware.
• Latency: The main bottleneck isn't the CPU processing, but the "Social API overhead"—the time it takes for a message to post and be retrieved by a peer.

Critical Analysis & Conclusion

Trans-SocialDP proves that social graphs are a viable "Identity and Discovery" service for distributed systems.

Pros:

• Built-in Trust: Reduces the "Sybil attack" risks inherent in anonymous P2P networks.
• Portability: Built in Java, it runs across Windows and Linux environments.
• Accessibility: Allows non-developers to create "Jobs" for their social circles.

Limitations:

• API Volatility: The system is highly dependent on third-party APIs (like Facebook's Graph API), which frequently change or restrict access.
• Network Privacy: Using "Wall Posts" as a messaging protocol is creative but potentially noisy and subject to platform spam filters.

Future Outlook: By adding Semantics (better matching of task requirements to hardware) and Reputation Systems, these "Trans-Social" networks could evolve into a true decentralized cloud, potentially competing with commercial services for specific, community-driven workloads.