Basicnet Protocol Documentation

Nobody has claimed this yet.

## Super Rough Version

**Message Types:**

1. Sub
2. Data (video segment)
3. Finish
4. Cancel
5. TranscodeResponse
6. GetMasterPlaylist
7. MasterPlaylistData
8. NodeStatusReq
9. NodeStatusData

**Node Roles:**

Broadcaster
* Sends video segments to its listeners
* If no listeners, drop the segments
* Broadcasts exist for each StrmID

Subscriber
* Receives video segments, and puts it into local video streams
* Subscribers exist for each StrmID

Relayer
* Receives video segments and calls the callback function.
* Relayers exist for each (MessageType, StrmID)

**Protocol:**

When a node wants to broadcast a stream:

* Create a local broadcaster, push Data to the broadcaster's listeners
* This can happen even when no one in the network wants the stream

When a node wants to subscribe to a stream:

* Create a local subscriber with the streamID
* This registers a callback, we usually put the data into a video stream in the caller
* Send Sub req to the network

When a node receives a Sub req:

* If there is a local broadcaster, add the requester's ID to its listener array
* If there is a local relayer, add the requester's ID to its listener array
* We assume the local relayer has already been created and the Sub req has been passed on.
* If there is a local subscriber and no local relayer, create a local relayer, add the requester's ID to its listener array
* If there is no local relayer, local subscriber, or broadcaster, create a local relayer, add the requester's ID to its listener array, and forward the request along.

When a node receives a Data req:

* If there is a local subscriber, send the data there
* If there is a local relayer, send the data there
* Otherwise, report an error

When a broadcaster finishes a stream:

* Send a Finish message to its listeners

When a node receives a Finish message:

* If there is a local subscriber, call it with EOF and delete it
* If there is a local relayer, forward the Cancel message to its listeners, and delete the relayer

When a node finishes subscribing (for example, player shuts down)

* Send a Cancel message to its upstream peer and delete the subscriber

When a node receives a Cancel message:

* If there is a local broadcaster, remove the peer from its listeners array.
* If there is a local relayer, remove the peer from its listeners array. If this makes the listeners array empty, remove the relayer.

The node sends a TranscodeResponse msg to the broadcasting node when it gets a transcode job from the blockchain.

* The broadcasting node should have set up a callback function to be able to receive the TranscodeResponse message (ReceivedTranscodeResponse)

StrmID might be confusing with MasterPlaylistID → Each master playlist contains multiple media playlists (represented by a single StrmID) - https://developer.apple.com/library/content/referencelibrary/GettingStarted/AboutHTTPLiveStreaming/about/about.html

The node populates the masterPlaylist map when it creates a new stream, and updates the masterPlaylist if it receives MasterPlaylistData.

The node sends out a GetMasterPlaylist request when it gets a media server video request

When a node receives a GetMasterPlaylist request:

* If we find the masterPlaylist in the local map, return it.
* If not
* If the nodeID from the streamID is the current node, we return a NotFound
* Otherwise, we forward it along, and create a local relayer if it doesn't already exist

When a node receives a MasterPlaylistData

* If we are the node requesting for it, give it to the requester
* If we are not the node requesting for it, we should have a local relayer, so relay the message along

NodeStatus works the same way as GetMasterPlaylist/MasterPlaylistData, it's used for getting a remote node's status (planning to use it for debugging)

No documentation file, test, or entry point is named in the issue. Start by locating the repository's existing documentation structure and compare it with the protocol described here; done means the message types, node roles, stream lifecycle, playlist handling, and node-status behavior are documented clearly and consistently.

Written by the indexing model from the issue text.