You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to be useful on mobile phones and other light hardware (storage and bandwidth impaired) swarm must support a "light mode".
Light on storage:
A swarm node without redundant local storage should be able to advertise to the network that it does not intend to store any chunks. Such a node will not be synced-to by the other nodes.
The node will count as a regular peer in the ordinary Kademlia routing as far as retrieval requests are concerned. It will receive, forward and process retrieval requests (and it may chose to cache the chunks).
However, it will not count towards any node's MostProxBin. This is because this bin is used for redundant storage and the light node will not be storing.
Light on storage and bandwidth:
A node should also be able to advertise that in addition to having no storage, it is also limited in bandwidth (eg a phone not on wifi). When a node indicates that it is in a bandwidth impaired state, its peers will no longer forward retrieval requests to the node. In practice the node is using its peers as swarm gateways.
The node does not qualify as a regular peer in either the MostProxBin nor any other Kademlia bin.
Perhaps it is wise to allow various swarm components to be modular, to be enabled/disabled by nodes at will. This could be part of the initial handshake, or they could also change their status later (such as when a phone connects to wifi, it might start forwarding requests)
So nodes would advertise services:
syncing: on/off (off means non-storing node)
forwarding: on/off (off means bandwidth impaired)
receipting: on/off (on means node is SWEAR registered and will issue storage receipts)
etc.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
In order to be useful on mobile phones and other light hardware (storage and bandwidth impaired) swarm must support a "light mode".
Light on storage:
A swarm node without redundant local storage should be able to advertise to the network that it does not intend to store any chunks. Such a node will not be synced-to by the other nodes.
The node will count as a regular peer in the ordinary Kademlia routing as far as retrieval requests are concerned. It will receive, forward and process retrieval requests (and it may chose to cache the chunks).
However, it will not count towards any node's MostProxBin. This is because this bin is used for redundant storage and the light node will not be storing.
Light on storage and bandwidth:
A node should also be able to advertise that in addition to having no storage, it is also limited in bandwidth (eg a phone not on wifi). When a node indicates that it is in a bandwidth impaired state, its peers will no longer forward retrieval requests to the node. In practice the node is using its peers as swarm gateways.
The node does not qualify as a regular peer in either the MostProxBin nor any other Kademlia bin.
Perhaps it is wise to allow various swarm components to be modular, to be enabled/disabled by nodes at will. This could be part of the initial handshake, or they could also change their status later (such as when a phone connects to wifi, it might start forwarding requests)
So nodes would advertise services:
syncing: on/off (off means non-storing node)
forwarding: on/off (off means bandwidth impaired)
receipting: on/off (on means node is SWEAR registered and will issue storage receipts)
etc.
The text was updated successfully, but these errors were encountered: