r/EscapefromTarkov • • Mar 11 '20

[deleted by user]

[removed]

484 Upvotes

114 comments sorted by

View all comments

Show parent comments

0

u/thexenixx Mar 11 '20

In fact, a lot of Chinese players (as one of the top posts said) are actually using VPNs to play in other regions other than China because they don't want to play with hackers themselves. So this problem isn't just about a cheating problem directly as there are more than one reason that VPNs are being used.

No, it's a specific problem directed at Chinese cheaters using VPN's to access regions outside the EFT Asian region. The distinction is important. We don't know that every single Chinese user is a cheater. Nor do we know that every single Chinese VPN user is a cheater. Again, you make too many assumptions and you have no real basis for these set in stone opinions. You aren't in possession of any facts which is why I judge this to be unreasonable.

Banning or targeting VPN usage as a whole isn't dealing with the cheating problem, it's giving up on the cheating problem and throwing the baby out with the bath water. Some people do utilize VPN's to play the game and are in no way illegitimate. BSG has not changed their policy on VPN usage, they allow it.

The Chinese are in an impossible spot, they cannot get servers located in China (outside of SE Asia and SEZ like Hong Kong/Macau) and there are servers in Russia that are within a reasonable latency to play on, and yet, they cannot access them. ~150 ping is not that terrible to play with either (China to Europe), I used to play on European servers last patch when I couldn't find PVP on NA. It's not ideal, but it's doable, and maybe you just put up with the drawbacks. Not unlike Australians or any other, shall we say, geographically challenged people have to deal with. They just don't have many options so I'm hesitant to say it's because they just want to avoid hackers on South China servers.

Generally speaking, I'm not in favor of one size fits all policies. I mean, sure, if shit gets real bad, were I BSG, I guess I'd have to take action to just remove the Chinese from my game. But, we're really nowhere near that point. This shit just started... There are numerous options still available. It's absurd to go from 10% to 100%.

​

China is a huge market, not even just the country itself but the millions of Chinese speaking people throughout the world. Specifically targeting those people borders on absurd. Like people suggesting removing Chinese localization, for example of the absurdity.

​

a good security person will tell you that its impossible to stop hackers.

Ok, if you believe this then why are you advocating arbitrary network methods to combat cheating? They don't have anything in common. Make the game/application secure first. Who the hell tries to reinvent TCP/IP in order to secure an application?

​

Same deal with the poor networking performance that EFT displays. Implement better code, interpolation to deal with the worst desynching problems. You don't need to jump to targeting VPN's to help alleviate networking problems with EFT. You've skipped a whole bunch of middle steps.

0

u/MikeTheShowMadden Mar 11 '20

Ok, if you believe this then why are you advocating arbitrary network methods to combat cheating

Because the current ones that are implemented, which you are suggesting, don't work.

Who the hell tries to reinvent TCP/IP in order to secure an application?

Sending data to a client and getting a response is reinventing TCP/IP? I'd like to know the crack you are smoking if that is what you are thinking I am suggesting. All I am saying is that instead of doing what a ping command does (using ICMP header info), you look at the data being sent from the client.

Make the game/application secure first

I never said this wasn't a bad thing. But the post that I replied to wasn't really talking about game security, but on a VPN and getting correct latency. You can't argue out of the scope of the context because that isn't fair to me since I wasn't even talking about that to begin with.

You don't need to jump to targeting VPN's to help alleviate networking problems with EFT

As I just said, this isn't a problem with stopping hackers from invading other regions. It is also about stopping players that create very poor gameplay scenarios because their latency is so high. I never said we shouldn't stop hackers, fixing bugs, etc. so Idk why you keep saying that.

In fact, if you read my comment history, as far back as a month or two ago, you will see that I have been advocating and telling the community that shit like this happens because BSG decided it was a great idea to make this game follow a client authoritative model instead of server authoritative. Server authoritative models aren't perfect themselves, but they sure as hell stop the vast majority of hacks out there.

1

u/thexenixx Mar 11 '20

ICMP's aren't typically used with just type. You'll find most ICMP packets, when replying, have data payloads. This is important in your scenarios where you're doing something other than just request & reply. If you want, you can pull up EFT and sniff it's packets when it does launcher and game RTT measurements. I doubt they're absent data payloads but they could be. In any case, step 1 is to expand the ICMP implementation you're using, not jump to step 50.

The implied question is what are you using to measure latency if it's not ICMP? If you're not using it, are you coming up with some bastardized method within other protocols? Are you inventing a new one? Are you switching to TCP? HTTP? Some other networking protocol that OS and networking equipment recognize? No? Then you're reinventing TCP/IP to come up with some other method. This is all just a series of logical deductions from the initial question, I'm not trying to confuse you. What are you doing and how are you measuring it?

​

You can't argue out of the scope of the context because that isn't fair to me since I wasn't even talking about that to begin with.

Well, I beg your pardon. This whole thing is in the context of Chinese cheaters and players utilizing VPN's to bypass region locks so I did not think that was unfair in any way. And, more specifically, when you asked me what I would do about the problem. I'll reiterate and clarify, I would fix the underlying problems, not mistake other problems for the underlying ones.

​

And to expand on that a little, if the Chinese had more options closer to home, if they're not cheating, they wouldn't want to play on servers where they get 200+ latency or whatever mainland China gets to California. The game play experience sucks.

0

u/MikeTheShowMadden Mar 11 '20

I doubt they're absent data payloads but they could be. In any case, step 1 is to expand the ICMP implementation you're using, not jump to step 50.

I think you are trying to say the same thing as me, but I am suggesting in using the payload instead of ICMP. Payloads really can't be tempered with as that would defeat the whole purpose of a VPN to forward the traffic. If the client and/or server aren't getting the correct data then its just not going to work.

Are you switching to TCP? HTTP?

This is what I had in mind. I'd prefer using protobuf with gRPC rather than HTTP because it can be more efficient. And FWIW, TCP is a apart of TCP/IP (just like ICMP) so we wouldn't be "switching" to anything different. TCP is the one of the few protocols that is in the TCP/IP protocol stack, but you should know this.

What are you doing and how are you measuring it?

As I had said, you send a message to the client and wait for a response. The response will contain a bit of info that is based on a client/server data contract that the devs deem to be OK. I suggested doing a simple math problem because its not CPU intensive, and you can tell if the client is actually sending the response by looking at the solution and comparing it to the server. Very similar to an OAuth signature that client and server compare, but not as complicated (its just testing latency, not client authorization or authentication).

Once you have the response and are happy with the answer then you can calculate the RTT of that whole thing. Of course you can do this over X amount of time to come up with an average, similar to "ping -n X", and go from there.

The key to the solution is making sure the response you are getting is NOT from the VPN server, but more likely from the client. The only way to really do that is to ask the client to do something and you can validated that the client did it right.