Sunshine Routine

What would Sunshine Hosts do (Needs reviewing)

Registration of Lender's Availability:

The lender's modified Sunshine application signals its availability to the Shaga system by creating and listing an NFT on the Solana-based marketplace. This process would include the Sunshine application sending a transaction to the Solana blockchain, which contains the relevant metadata about the gaming server (e.g., performance specifications, location data, rental cost, etc.).

Blockchain Confirmation and Synchronization:

After the transaction is confirmed on the Solana blockchain, the new state (i.e., the availability of the lender's gaming server) is propagated across the network. This is done through the process of blockchain synchronization, where each node in the network updates its copy of the blockchain to reflect the most recent state.

Distributed Hash Table (DHT) for Decentralized Discovery:

To allow efficient, decentralized discovery of available gaming servers, a Distributed Hash Table (DHT) can be used. In this case, the DHT would serve as a decentralized database of available lenders, which is maintained collectively by the nodes in the Shaga network. The DHT would map each lender's unique identifier (e.g., their blockchain address or NFT ID) to the metadata associated with their gaming server.

Borrower Queries for Available Lenders:

When the borrower opens the Shaga-Moonlight application, it sends a query to the DHT to find available gaming servers near their location. This query could be structured as a search for all entries in the DHT that match certain criteria (e.g., servers located within a certain radius of the borrower's location).

DHT Returns List of Available Lenders:

The DHT responds to the borrower's query by returning a list of available gaming servers that match the search criteria. This list is then displayed to the borrower in the Shaga-Moonlight application, allowing them to select a lender and initiate the rental process.

Rental Transaction:

Once the borrower has selected a lender, the Shaga-Moonlight application sends a transaction to the Solana blockchain to initiate the rental process. This transaction includes the borrower's payment in USDC, as well as the unique identifier of the lender's NFT.

Blockchain Confirmation and Rental Activation:

After the rental transaction is confirmed on the Solana blockchain, the Shaga system activates the rental agreement. This process involves the Sunshine application on the lender's gaming PC receiving a notification about the rental, and the Moonlight application on the borrower's device being granted access to stream games from the lender's PC.

Connection Termination:

The connection with the borrower ends, either due to the borrower's request or after a predetermined period. The termination is typically signaled by a TCP FIN (finish) or RST (reset) packet from the borrower's device to the lender's node.

Updating Node Status:

Upon receiving the termination signal, the lender's node updates its internal status to "available." This status indicates that the node is ready to serve a new borrower.

Broadcasting Availability:

The lender's node, specifically the modified Sunshine application, then initiates an availability broadcast. This broadcast is propagated throughout the network via the DHT protocol discussed earlier. The broadcast message includes the lender's node identifier (e.g., IP address) and its new status (i.e., "available").

DHT Update:

Upon receiving the broadcast from the lender's node, the DHT nodes update their records, marking the lender's node as available. This update is then propagated throughout the network, ensuring all DHT nodes have the most recent information.

Availability Display:

The updated status is then reflected on the Shaga-Moonlight application on potential borrowers' devices. The map or list of available servers is updated to include the newly available lender's node.

Awaiting New Connection:

After successfully broadcasting its availability, the lender's node returns to a standby state, ready to accept a new connection request from a borrower. This process repeats each time a borrower disconnects, ensuring the lender's node is always ready to serve new borrowers when available.