The following question and subsequent answer aim to characterize what role TSSP plays in a logistical network deployment -
Q: "Given a logistical network, what can I do with it?" A: "Following this protocol/spec, you can at least achieve [these operations]."
TSSP implementations depend on three distinct services:
- metadata respository - where the information usually contained in exnodes will be hosted
- storage resource discovery - where a list of available storage servers can be found
- and storage itself - host running an IBP-capable service (aka depot)
When these are defined for a given logistical network, TSSP implementations can perform the following operations:
- send data using static or dynamic routes/channels
- receive data from a filled channel
- change the duration of a channel
- and increase or reduce a channel's data capacity.
Thus far we have broken down the operations into reusable steps, have characterized the behavior of TSSP during each step when faced with a series of possible failures, and have outlined the content of the messages needed to complete each transaction.
Pending items include:
- for which of the three services does TSSP need authentication
- which end-to-end services should be standard for TSSP
We expect to have a working implementation available by the end of February.
Nevoa plans to have an area of their website where developers can validate implementations of IBP, exMSP, and RDP services according to the latest specifications of each protocol. By coding against validated services, we hope to ensure the quality of our documentation and make troubleshooting easier.