Gamers use case
dmorn opened this issue · 1 comments
Make booster
be helpful for gamers that suffer of high Jiffer/Lag. As soon as games mostly work using UDP, we have to either implement UPD Associate handler in our proxy to support UDP proxing, or change proxy library (thing that I'm considering, I'm interested in brook).
Then we have to implement the strategy & policies required to "reserve" a portion of the network channel for the game's traffic.
Updated scenario considering a full rewrite:
without booster
The gamer wants to play a game, let's say LoL, at his home he has an ADSL shared with the rest of his roommates. When he tries to play, however, he suffers from sudden changes in pinging, the net is very unstable. He notices that the others are using the connection to download large files. Then he uses his mobile phone in tethering, but Windows starts him up with background updates that he can't stop, and he finds himself pointing to the head (true story).
with booster
Remaining connected to the ADSL, it also connects the mobile phone (always tethered) to the computer (with the cable), and activates booster
. ~ Leaving aside how the user chooses, or booster
chooses, to go into "gaming" mode trying to improve the LoL process ~ At this point the network traffic is manipulated to allow the user to play without lag.
Proposal
How could it act at the network level? Traffic could be distributed between the two interfaces, but particular attention should be paid to where to send the most critical LoL packets, which should use the path with the lowest RTT. You could proceed by measuring the RTT of LoL packets, initially duplicating them and sending them to both interfaces. When you know the best performing path, you can stop duplicating packets but monitor the RTT trend. If there is a variation, you return to duplicate packets to choose again where to send them.
Interesting technologies:
pfctl
(bsd systems): for packet forwardingtpdump
(orpcap
): to monitor the interfacestun/tap
: to manipulate traffic
Possible implementations
-
Capture the traffic of the process concerned (LoL in this case) and forward it to the booster tun. Based on the information collected (in this case about the RTT), it will decide where to write the packages. (it does not allow to distribute all the traffic, but only where to send the LoL packages, i.e. the "secondary" interface could be left unused)
-
Monitor all traffic, and add/remove live packet forwarding rules based on information collected and decisions made