-
Notifications
You must be signed in to change notification settings - Fork 106
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
Out of order packets with aggregation. #43
Comments
Yes, it is already planned for 0.3.x :) |
Oh nice thats great to hear! How would you deal with this? Numbering tagging all outgoing and incoming packets on sequential order and drop the rest? Can't wait for this :-) |
|
we are not going to fully reorder packets (this is the protocol jobs) but as you said we will add some latency on fast path to build a virtual path with stable statistics to help tcp and others. |
Wouldn't it be easier like MLVPN does it? Simply tag UDP packets on proper sequence, and on the end point read those in a buffer. If packets exceed set buffer just discard. Otherwise re-order them. UDP (or UDP over UDP) wont ever re-order itself because it doesn't know any better :P Only TCP over UDP shouldn't be an issue... |
A full reordering should not be necessary, but I will take time to explore all solutions don't worry :) |
Hello, |
And newer version never comes ... :-) |
just for @TalalMash : 2 years ago, newer version never comes :-) |
Example: setup two paths At this point, the client's routing table has not changed. However, I should set default route is tun0. Now, I have to make sure that I can connect to the server IP via usb1 usb2.So, I should set, And, I use ping 10.0.1.1/tcpdump -i usb1/tcpdump -i usb2 In addition, I also tried to create two routing tables, but still not.I don't know what's wrong. Hope to get some help from you, thanks! |
Hi!
For pure gaming I use Glorytun UDP atm.
But Out of order packets with aggregation causes some fluctuating packet loss due to OoO i presume.
Is there any way to deal with this? Latency of all 3 WAN's arent that far apart so that is probably an issue, would adding some send delay to 2nd and 3rd WAN solve this somewhat? So it acts more as failover rather than jittery udp data.
The text was updated successfully, but these errors were encountered: