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.

Sign up for GitHub

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

Jump to bottom

Proposal: Add higher level mux to coreutils #8

Open
ChrisSchinnerl opened this issue Jan 17, 2024 · 3 comments · May be fixed by #17
Open

Proposal: Add higher level mux to coreutils #8

ChrisSchinnerl opened this issue Jan 17, 2024 · 3 comments · May be fixed by #17

Comments

@ChrisSchinnerl
Copy link
Member

When working with various types of clients (http, sql,...) they usually manage connections transparently. Meaning that they try to be smart about pooling connections and fixing interrupted connections. I think it would be useful to have a higher level mux in coreutils which behaves similarly.

Essentially when a renterd instance has 50 contracts I'd like to be able to create one mux for each and not have to worry about them ever again. They would try to keep the TCP connection alive for a while and if the connection breaks due to being inactive for too long, they would establish a new one implicitly on the next call to NewStream.
@n8maninger
Copy link
Member

I don't have strong feelings about where it ends up; coreutils is fine. Keeping it in renterd would also be fine.

My one request would be to drop connections that have been inactive for a significant amount of time rather than trying to keep them alive. The handshake overhead isn't bad, and keeping everything alive forever would be resource-intensive. Smart connection pooling, automatic retries, and fixing interrupted connections are solid higher-level optimizations.

@ChrisSchinnerl
Copy link
Member Author

The reason why I'd like to have that in coreutils is mostly reusability. e.g. explored might also be interested in that and I'm generally not a fan of cross-importing any of the larger repositories containing our "deliverables" (hostd, walletd, renterd, explored)

@lukechampine
Copy link
Member

My general stance on reuse here is:

  1. Implement it locally.
  2. If it seems like another repo needs it, copy it.
  3. Maintain both copies for a while. Do they converge, or diverge?
  4. If they converge, move the implementation to coreutils.

In this case specifically, we're at step 1; we don't yet have another repo that needs this thing, so it should live in renterd for now.

@ChrisSchinnerl ChrisSchinnerl linked a pull request Mar 14, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
Sia
Status: In Progress
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

RHPv4 Client SiaFoundation/coreutils
3 participants
@lukechampine @ChrisSchinnerl @n8maninger