Drain the Pipeline

[dnwiebe]

As things stand at the time of this writing, when the exit Node is producing a stream of data that the originating Node decides it no longer wants to pay for, the originating Node removes the relevant StreamKey from its ProxyServer's StreamKeyed HashMaps and sends a ClientRequestPayload_0v1 package to the exit Node with last_data = true. The intent is to have the exit Node's ProxyClient break its connection with the server so that the stream of data stops.

However, even if this is accomplished, there will still be a few CORES packages that are already on their way that will arrive at the originating Node's ProxyServer after the last_data = true ClientRequestPayload_0v1 is sent. Since the ProxyServer has removed all trace of that StreamKey from its HashMaps already, though, it will have no idea how to pay for those last few CORES packages, and so the exit Node and the relay Nodes--which moved that data in good faith--will remain unpaid, and eventually the originating Node will be banned.

The originating Node needs to pay for the good-faith work of the exit and relay Nodes, even though it meant to refuse those last few packets, and even though the stream to the browser will be closed by the time they arrive, so they'll just be discarded.

Task: Modify the ProxyServer so that when it directs an incoming data stream to be terminated, it doesn't immediately purge the StreamKey from its HashMaps, but instead schedules an actor message containing the StreamKey to be sent to itself after a reasonable number of seconds. When it receives that message, it should purge the StreamKey.

Note: There may be a temptation to design the solution so that the StreamKey stays alive as long as it's being used, and only dies after it has been inactive for awhile. Avoid this: it's an attack surface that will be exploited by evil Nodes that will continue sending data after they've been told to shut up, because they can continue to "earn" money that way. Applying a definite time limit after the last_data = true will not prevent this kind of attack, but it will limit its effectiveness.

As long as incoming data is being consumed by the browser, the spoofing capability of an evil Node is limited, because the browser will detect any TLS data manipulation and protest. However, once the browser shuts down a stream and can no longer see what's on it, an evil Node can send whatever it wants.

[kauri-hero]

Need to clarify this work alongside the #801 card. Its likely that @utkarshg6 is working on the functionality described in #801 , rather than this card

[dnwiebe]

Idea for testing: Set up a Node with log-level debug, let it connect to the Network, and then start watching a YouTube (or other) video. A few seconds into the video, stop the transfer and wait for everything to stabilize. Then stop the Node and look at the log file. Do you see notifications about ordering the stream shut down, receiving a few straggling packets, and then retiring the stream key? If so, that's cool: it works. If you see logs about receiving data for an unknown stream key, that's a problem; it means the issue isn't fixed yet.