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

stream sending buffer size and how much left #1838

Closed
szguoxz opened this issue Apr 28, 2024 · 3 comments
Closed

stream sending buffer size and how much left #1838

szguoxz opened this issue Apr 28, 2024 · 3 comments

Comments

@szguoxz
Copy link

szguoxz commented Apr 28, 2024

for bistream or unistream, is there anyway to know how big is the sending buffer, and how many bytes left in the buffer?

@Ralith
Copy link
Collaborator

Ralith commented Apr 28, 2024

There are multiple limits on the amount of data you can send at any particular point in time. Some are under the sender's control, some the receiver's (flow control). Flow control limits aren't currently exposed directly. They could be, but that information might become out of date immediately. What are you trying to achieve, specifically?

@szguoxz
Copy link
Author

szguoxz commented Apr 28, 2024

I am creating a VPN between China and USA. but the connection is not stable. I have a relay node in HK. So I created two connections between my China and USA nodes. One direct, another one relay by the HK nodes.

When I send data from USA to China, I want to intelligently pick which connection to use. If one is seriously delayed, I will use another one.

On the receiving side, my node is intelligent enough to drop duplicate data ... etc.

So, my main problem is: How to determine which connection is in relatively bad shape? Which one should I use at the moment?

Thanks.

@Ralith
Copy link
Collaborator

Ralith commented May 7, 2024

Hmm, I know I typed up a response to this, but I must have forgotten to send it...

"bad shape" and "not stable" are vague. Are you trying to use the connection with the lowest latency? The highest throughput? The least packet loss? Some weighted combination of those? Most likely you should be looking at PathStats (via Connection::stats), rather than anything to do with stream buffer state.

@szguoxz szguoxz closed this as completed May 13, 2024
@djc djc closed this as not planned Won't fix, can't repro, duplicate, stale May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants