Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmitter-Receiver Communication on Proxy Client #796

Open
dnwiebe opened this issue May 17, 2024 · 0 comments
Open

Transmitter-Receiver Communication on Proxy Client #796

dnwiebe opened this issue May 17, 2024 · 0 comments
Projects

Comments

@dnwiebe
Copy link

dnwiebe commented May 17, 2024

Here's how TCP connections are shut down.

  1. 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.
  2. 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.
  3. 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.

@dnwiebe dnwiebe created this issue from a note in MASQNode (New) May 17, 2024
@kauri-hero kauri-hero moved this from New to Ready for Development in MASQNode May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🔖 Ready
MASQNode
  
Ready for Development
Development

No branches or pull requests

1 participant