Slashdot Mirror
Ask Slashdot: VPN Setup To Improve Latency Over Multiple Connections?
blogologue writes I've been playing Battlefield for some time now, and having a good ping there is important for a good gaming experience. Now I'm in the situation where I have mobile internet access from two telecom companies, and neither of those connections are stable enough to play games on, the odd ping in hundreds of milliseconds throws everything off. How can I setup a Windows client (my PC) and a Linux server (in a datacenter, connected to the internet) so that the same TCP and UDP traffic goes over both links, and the fastest packet on either link 'wins' and the other is discarded?
(Have your own question for the teeming masses? Ask away — be sure to include appropriate detail and context — via the Slashdot submission form.)
This is why local LAN play with your buddies beats some unknown remote server. Plus, then you can keep playing after the central server is taken offline.
What's that? Your favorite game doesn't support LAN play? Well, better support the ones that do, and not support the ones that don't, if you want this option to remain viable into the future.
That's true, but it seems that the real problem the OP is trying to solve is huge variance in the latency (i.e. jitter) - that is, the idea is to trade a very small amount of extra latency for the latency being much more consistent (without the massive spikes currently being seen). I'm not sure how well it would work in practice (e.g. if some of the spikes are due to local RF interference, it's possible they will affect both connections at the same time), but there's potential at least for a much smoother gaming experience.
Need to type accents and special characters in Windows? Use FrKeys
How can I...
Simple. Just write a custom driver on both the Windows and Linux boxes to handle both ends as described (you'll want the traffic duplicated both ways, I'd imagine, since you're not just dealing with one-way communication here).
I doubt there's anything off the shelf that will handle what you want. Sounds like a fun project... but don't undertake this unless you think the project will be as fun to work on as actually playing your game. And be prepared to drop a hundred hours into it (depending on your coding abilities and familiarity with the associated APIs).
Any sufficiently simple magic can be passed off as mere advanced technology.
Sounds like an interesting problem; I check the comments to see what solutions to the specific problem laid out might exist. Instead, the comments show varying levels of misunderstanding the question and/or the proposed solution.
The proposed solution is simple:
1. Client duplicates packets over two mobile links to an intermediate, user-controlled server.
2. This server sorts things out and discards the losing packet, and forwards the winner on to the real gaming server.
Both client/intermediate server are under the control of the user, with two possible links. The communication protocol between these two nodes can be user-defined to anything. The question was how to configure this.
"How will the server deal with duplicate copies?" Duh, the gaming server won't. That's what the intermediate server is for. Did you read the OP?
"A VPN will add to the latency." Yes, but that wasn't the problem. The problem is random jitter on one of the links.
"Local LAN play is better!" Well yes, but that's not remotely related to the problem. Maybe he doesn't have anybody local to play with regularly?
"Use this exotic hardware solution." Why, if the problem can be solved for free with software?
"Your latency comes from your mobile links." Duh, but he already measured the main problem to be random jitter. Why not comment on the proposed solution?
The only concern I read that is accurate was that an RF disturbance could interrupt both links.
http://www.multipath-tcp.org/
of course, this requires the other end to support it, which it probably doesn't.
I've also considered selling "multipath vpn" service... the idea being that people with two DSL providers (and one dsl and one cable) provider would setup their gateway (or use a linux box that I sell them and manage) to send all packets out VPNs on both connections, to my own vpn endpoint in a datacenter. The idea being that then my server on the other end of that connection would take the first packet and send it on to it's destination. Assuming that my datacenter has a good connection, you would suffer less packet loss, and less latency.
My solution here would solve the problem if the problem is latency/loss on your last mile connection. It would not help at all if the problem was further along the connection, while multipath-tcp would
Hi, I'd like to hear a TCP joke
Hello, would you like to hear a TCP joke?
Yes, I'd like to hear a TCP joke
Okay, I'll tell you a TCP joke
Okay, I'm ready to hear a TCP joke
Okay, I'm about to send a TCP joke, that'll last for 10 seconds. It has two characters, it does not have a setting, it'll end with a punchline.
Okay, I'll get your TCP joke, that'll last for 10 seconds. It has two characters, it does not have a setting, it'll end with a punchline.
I'm sorry, your connection has timed out
On the other hand, I could successfully tell you an entire UDP joke, but you might not get it.
Ask me about repetitive DNA
Doesn't TCP require it come back on the path too?
Absolutely not. Nor does it expect that to usually happen. The routes in opposite directions are often different. (For starters, they're based on the local knowledge of the routers at opposite ends of the path, which are typically familiar with their neighborhood and may have no clue about what things are like near the other end.)
The routes of diffetrent packets in the same direction are often different, too (like for load-balancing by throwing alternate packets down two slower links to get an effectively faster link). Every packet is potentially routed differently (though routing protocols like label switchingmay often set up connection-like shortcuts that make consecitve packets take the same path - to speed things up).
What matters is just that they get to the same ENDPOINT. Some may be silently lost. Some may be duplicated. Some may arrive out of order (like when a route changes and later packets get there faster).
It's been like this since IP, UDP, and TCP were invented. It was a core principle of their invention.
= = = =
Having said that:
Deviation (other than packet drops) from simple first-in-first-out packet flow tend to be rare. So not all servers and/or clients handle them well. (TCP will sort out missing and misordered packets on the receiving end - sometimes at substantial cost in buffering and latency. UDP will not - for simplicity, speed, and for when occasional lost packets are less of a problem than high latency and occasional long delays. So if the server and/or client can't handle transmission problems well, performance may suffer or functionality simply fail.)
Many networking company customers of high-speed router makers make the additional requirement that a stream of packets coming in one particluar interface from one particular source and going out another particular interface to a particular destination are not reordered. That's a pain when the router's guts are a sea of little processors each handling packets individually, so additional special purpose hardware may be added to track packet order and insure things don't get reordered between input and output queues.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I find it hard to imagine that it would (at least routinely) be faster than using his current wireless setup to route his traffic from his desktop ... through his cable modem ... through his ISP ... through a remote datacenter (somewhere) ... to the Battlefield servers
I have no problem at all believing that. The OP says he is using two MOBILE access devices from two (wireless) carriers and is (if I read him right) experiencing substantial intermittent (but separate) delay and/or drop events in both of them. If he throws each packet down both of them and the first one to arrive at the data center gets to the game server, the packets that are lost or delayed on BOTH paths will be very much rarer and his gaming experience will be substantially improved.
Yes, he'll get a little extra latency on the fast packets - which is most of them. But server farms generally have fat and blazingly fast backbone connections, so it shouldn't be a lot added. A small price to pay to make almost ALL packets arrive reasonably quickly and almost NONE experience big delays or loss.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
http://speedify.com/features/
This kinda sounds like what you're looking for.
Chas - The one, the only.
THANK GOD!!!
TCP can deal with duplicate packets from the same endpoints. Sending duplicate packets over two entirely seperate routes would require that the server be able to deal with demultiplexing the requests. I seriously, seriously doubt that any game servers are set up to do that. As far as the game server would be concerned, it's two seperate clients for the same account connected.
I do not fail; I succeed at finding out what does not work.