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
One side (A) decides it wants to shut down the connection, and sends a shutdown packet to the other end. This is the last transmission over the stream that A will make.
The other side (B) may not be finished yet. When B receives the shutdown packet, it will finish sending whatever data it has remaining, and then it will send a shutdown packet of its own. At this point, B is finished both transmitting and receiving, and will reclaim whatever resources it had dedicated to the connection.
A will receive the final data from B, and then the shutdown packet. When it gets the shutdown packet, it is finished receiving as well, and will reclaim its own resources. At this point, the connection is gone.
We've discovered that sometimes (particularly in streaming situations) a badly-designed server can keep sending megabytes and megabytes of data in step 2, after the browser has made clear its disinterest in the data. In this case, the stream receiver in the Proxy Client will continue generating CORES packages and sending them across the MASQ Network to the originating Node, where the Proxy Server will discover, for each of them, that the stream key (along with the TCP stream back to the browser) has been discarded, and there's nothing to do but throw away the data and pay the relay and exit Nodes for it to avoid being banned.
This can produce thousands and thousands of log messages like this:
2024-05-16 09:30:17.608 Thd20: WARN: ProxyServer: Discarding 16384-byte packet 329 from an unrecognized stream key: 5tMAZkzKUhPiz+K4RnA3WWQBwvM; can't send response back to client
Task:
Modify at least the ProxyClient, but probably also the ProxyServer, so that connections that are in the process of shutting down (are at Step 2 above) can't continue to limp along forever, but are restricted to some reasonable number (maybe 10) of additional exchanges, at which point MASQ will forcibly terminate the virtual connection, and the originating Node will not be charged for any more data it doesn't want.
The text was updated successfully, but these errors were encountered:
Here's how TCP connections are shut down.
We've discovered that sometimes (particularly in streaming situations) a badly-designed server can keep sending megabytes and megabytes of data in step 2, after the browser has made clear its disinterest in the data. In this case, the stream receiver in the Proxy Client will continue generating CORES packages and sending them across the MASQ Network to the originating Node, where the Proxy Server will discover, for each of them, that the stream key (along with the TCP stream back to the browser) has been discarded, and there's nothing to do but throw away the data and pay the relay and exit Nodes for it to avoid being banned.
This can produce thousands and thousands of log messages like this:
Task:
Modify at least the ProxyClient, but probably also the ProxyServer, so that connections that are in the process of shutting down (are at Step 2 above) can't continue to limp along forever, but are restricted to some reasonable number (maybe 10) of additional exchanges, at which point MASQ will forcibly terminate the virtual connection, and the originating Node will not be charged for any more data it doesn't want.
The text was updated successfully, but these errors were encountered: