Skip to content
This repository has been archived by the owner on Apr 2, 2020. It is now read-only.

Gamers use case #41

Open
dmorn opened this issue Apr 9, 2019 · 1 comment
Open

Gamers use case #41

dmorn opened this issue Apr 9, 2019 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@dmorn
Copy link
Member

dmorn commented Apr 9, 2019

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.

@dmorn dmorn added the enhancement New feature or request label Apr 9, 2019
@dmorn
Copy link
Member Author

dmorn commented May 31, 2019

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 forwarding
  • tpdump (or pcap): to monitor the interfaces
  • tun/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

@dmorn dmorn added the help wanted Extra attention is needed label May 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant