EPTThe Big Programming Thread - Page 498
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
delHospital
Poland261 Posts
| ||
|
Manit0u
Poland17496 Posts
![[image loading]](http://i.imgur.com/4U9lDod.gif) | ||
|
Zocat
Germany2229 Posts
On July 09 2014 01:13 urboss wrote: You could in theory solve the problem by encrypting all the game state variables. My guess is that this would: - be too much of a pain in the ass - slow down the game noticeably - assume that this is an actual issue for Blizzard (they can already detect maphacks with Warden) http://crypto.stanford.edu/~dabo/pubs/papers/onlinegames.pdf Is a good paper on that. And no, the downsides are barely noticeable. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
aksfjh
United States4853 Posts
On July 10 2014 00:40 Nesserev wrote: As far as I can see, you're the troll here... It's just another step in the cat-and-mouse game, there's probably a way to 'one-up' it. The only way to really stop maphacking, is by making sure that the information is not on the other person's computer, but this isn't very practical either. Also, it only addresses one attack vector in a very expensive way... I'm not a crypto-junkie, so maybe I'm missing something, but how would the client not have the same information for decoding the encryption that the software/game does and seeing the intersection? | ||
|
delHospital
Poland261 Posts
On July 10 2014 00:40 Nesserev wrote: As far as I can see, you're the troll here... It's just another step in the cat-and-mouse game, there's probably a way to 'one-up' it. The only way to really stop maphacking, is by making sure that the information is not on the other person's computer, but this isn't very practical either. Also, it only addresses one attack vector in a very expensive way... Let me quote you something from the paper: We assume that the game has a peer-to-peer architecture, as is the case for Starcraft II and most other fast paced online games. That is, each party communicates directly with the others without using a central server to manage the game state. In slower games like World of Warcraft, where a central server runs the game, security against passive attacks is straightforward since the server only tells each client precisely what the client is allowed to know. As we will see, security in fast peer-to-peer games is much harder. You can keep shouting "client-server", saying that I sound illogical, and calling me a troll all you want. That doesn't change reality. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
Shield
Bulgaria4824 Posts
I'm being interviewed about this more and more and I'm not too sure if I do well enough. For example, I've been asked what a class is, and I said "a structure of data & methods" but I guess that's actually an object, and the class is just a blueprint. Overall, I want to clear up my own confusion regarding the basic OO topics. If any of you isn't embarrassed, can you share how long after your graduation you were recruited to work as a software developer? I'm at this stage and I'm getting impatient. I'm trying to avoid the infamous 'unemployed' circle. | ||
|
netherh
United Kingdom333 Posts
On July 10 2014 02:55 Nesserev wrote: Holy sh!t, did you just find an error in a paper by students from Stanford. This explains why I was confused while reading the later segments of the paper, they're treating SC2 as a P2P game... That's weird, because a simple netstat proves that it's not P2P. Peer-to-Peer would imply that two users make a direct connection, and share resources directly, which is simply not happening. Reading around a bit indicates that it's both. i.e. It's not strictly peer-to-peer as there's no direct connection with the other player(s). Everything is routed through a Blizzard server. However, the server may not do any actual validation, but just passes data from one "client" to the other. (It avoids disconnecting-to-avoid-loss tricks though). As far as spectators causing lag goes -> I'm not sure how well defined a "spectator" is in terms of Blizzard's networking model. With GameHeart style maps, and custom games, you can switch players from spectator to player and back again. I imagine the engine treats everyone connected as a player. | ||
|
delHospital
Poland261 Posts
On July 10 2014 02:55 Nesserev wrote: Holy sh!t, did you just find an error in a paper by students from Stanford. This explains why I was confused while reading the later segments of the paper, they're treating SC2 as a P2P game... That's weird, because a simple netstat proves that it's not P2P. Peer-to-Peer would imply that two users make a direct connection, and share resources directly, which is simply not happening. And to think that the paper received the "Best Student Paper" award at the 2011 IEEE Symposium on Security and Privacy despite making such a grave error! | ||
|
Nesserev
Belgium2760 Posts
| ||
|
delHospital
Poland261 Posts
Sorry for repeating this question for the third time, but this doesn't let me sleep at night: given the above, can two players in a 1v1 game be affected by lag differently? Does an American playing on the American server have an advantage in terms of latency over his Korean opponent? If so, how is it possible? | ||
|
netherh
United Kingdom333 Posts
On July 10 2014 05:32 delHospital wrote: Sorry for repeating this question for the third time, but this doesn't let me sleep at night: given the above, can two players in a 1v1 game be affected by lag differently? Does an American playing on the American server have an advantage in terms of latency over his Korean opponent? If so, how is it possible? The server may not do validation (hence blink hacks), but it's probably involved in game state updates, synchronisation and timing. (Note, I'm definitely guessing here... but from plenty of experience playing with a dodgy connection it's clear that when you press a button, and when the action actually "happens" are very different things). With a local server, the player sends an update to the server. The actions in the update are applied / acknowledged / synched as taking place when that data arrives at the server, not necessarily when they are sent by the local machine. The distant player's updates get applied after a much longer round trip to the server, so he gets lag before his units respond to commands. If when data arrives at the server is the "official" time that those actions took place, the distant player has more time before his machine reflects the correct state of the enemy units too, and so his reaction time is also going to be longer. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
netherh
United Kingdom333 Posts
On July 10 2014 07:27 Nesserev wrote: The terms Client-Server and P2P only reflect on how information is shared, and the connections that a computer makes. If that information isn't relayed from one computer to another through a direct connection, it's not P2P. It's that simple... But in games, the term "server" is also used to indicate a machine running an authoritative simulation of the game used as a base by other players. The SCII server doesn't appear to do that. The "clients" are clearly not dumb terminals (hence "results disagree" and blink hacks) It's a classic peer-to-peer lockstep model with a "server" in the middle to route stuff and synchronise, no? | ||
|
delHospital
Poland261 Posts
On July 10 2014 07:27 Nesserev wrote: + Show Spoiler + On July 10 2014 04:23 netherh wrote: Reading around a bit indicates that it's both. i.e. It's not strictly peer-to-peer as there's no direct connection with the other player(s). Everything is routed through a Blizzard server. However, the server may not do any actual validation, but just passes data from one "client" to the other. (It avoids disconnecting-to-avoid-loss tricks though). As far as spectators causing lag goes -> I'm not sure how well defined a "spectator" is in terms of Blizzard's networking model. With GameHeart style maps, and custom games, you can switch players from spectator to player and back again. I imagine the engine treats everyone connected as a player. The terms Client-Server and P2P only reflect on how information is shared, and the connections that a computer makes. If that information isn't relayed from one computer to another through a direct connection, it's not P2P. It's that simple... On July 10 2014 05:32 delHospital wrote: Okay, so thanks to posts by R1CH, a paper by Stanford students, and lots of circumstantial evidence, now we all should be convinced that StarCraft II is a peer-to-peer game, where the game state of all participants is synchronized. Sorry for repeating this question for the third time, but this doesn't let me sleep at night: given the above, can two players in a 1v1 game be affected by lag differently? Does an American playing on the American server have an advantage in terms of latency over his Korean opponent? If so, how is it possible? Seriously, you have a thick skull... Anyway, yes, a person who lives closer to a server will have an advantage over his opponent. Let's assume that processing time is nihil, and that communication in both ways (player -> server, server -> player) takes the same amount of time. Imagine if person A(merica) is playing against person K(orea). It takes 25 ms for A to send data to the server, and another 25 the other way around. Overall: 50 ms It takes 100 ms for K to send data to the server, and another 100 ms the other way around. Overall: 200 ms (I'm pretty sure it takes longer in reality.) There's usually a buffer time that divides everything in frames (not to be confused with rendering frames)... let's assume that SC2 has a 125ms buffer. During that 125 ms buffer, all incoming information is processed, and when it's done, information is send back. Player A Best case player A: If player A sends a message at 100 ms into the current buffer, it takes 25 ms to send the information, it arrives at 125 ms (just before buffer ends), takes 25 ms to send information back. -> 50 ms after input, the change is shown on the screen Worst case player A: If player A sends a message at 101 ms into the current buffer, it takes 25 ms to send the information, it arrives at the beginning of the next buffer (125 s buffer time), it takes 25 ms to send the information back. -> 175 ms after input, the change is shown on the screen If a message is send before 100 ms (which is the case for most messages) into the current buffer, it still shows up in the current buffer. Hence it still feels fast. Only messages after 100 ms will feel slightly slower. These are the times: + Show Spoiler + Frame Time, Arrival at Server, Departure at Server, Buffer Time, Onscreen Delay, Frame Player K Best case player K: If player K sends a message at 25 ms into the current buffer, it takes 100 ms to send the information, it arrives at 125 ms (just before the buffer ends), takes 100 ms to send information back. -> 200 ms after input, the change is shown on the screen Worst case player K: If player K sends a message at 26 ms into the current buffer, it takes 100 ms to send the information, it arrives at the beginning of the next buffer (125 s buffer time), it takes 100 ms to send information back. -> 325 ms after input, the change is shown on the screen If a message is send before 25 ms (only 1/5th of the messages), they will arrive in the same buffer, but they will feel slow because of the lag. Most messages will arrive in the next buffer, so most commands will feel significantly slower. These are the times: + Show Spoiler + Frame Time, Arrival at Server, Departure at Server, Buffer Time, Onscreen Delay, Frame Reacting to Opponent's Moves If A performs an action, it takes 25 ms to get to the server, add buffer time, and another 100 ms to arrive at K. If K performs an action, it takes 100 ms to get to the server, add buffer time, and another 25 ms to arrive at A. The most important part is the last part, because it shows how fast a person can react to an action. - A sees an action by K 25 ms after a buffer has ended; K only sees his own action after buffer time + 200 ms. - K sees an action by A 100 ms after a buffer has ended; A sees his own action after buffer time + 50 ms. A will be able to react significantly sooner to the actions of player K, than vice versa. Overall Player with less lag will be able to act faster, and react faster. There are other things involved, like game physics, that can change the feel of the game, and make it feel even slower/faster. I think this will be an interesting article for you: http://buildnewgames.com/real-time-multiplayer/ I know how a client-server game works, no need to explain that in a 1000 word essay. If you believe that SC2 is not p2p, then assume we're talking about WC3. Is lag always symmetrical in WC3? | ||
|
delHospital
Poland261 Posts
On July 10 2014 07:25 netherh wrote: The server may not do validation (hence blink hacks), but it's probably involved in game state updates, synchronisation and timing. (Note, I'm definitely guessing here... but from plenty of experience playing with a dodgy connection it's clear that when you press a button, and when the action actually "happens" are very different things). With a local server, the player sends an update to the server. The actions in the update are applied / acknowledged / synched as taking place when that data arrives at the server, not necessarily when they are sent by the local machine. The distant player's updates get applied after a much longer round trip to the server, so he gets lag before his units respond to commands. If when data arrives at the server is the "official" time that those actions took place, the distant player has more time before his machine reflects the correct state of the enemy units too, and so his reaction time is also going to be longer. Thanks for this post. It's all guesswork, but it does make quite a bit of sense. Below are some simple calculations, they seem to suggest that it is indeed possible for lag to be asymmetric. Let's assume the following:
A -- 25 ms -- C -- 100 ms -- B Now, if C is just a dumb relay, then A, when sending to B a list of actions to happen in a frame, must do it 25+100+delta ms in advance (delta to account for latency variations and processing time). B->A also must send 100+25+delta ms in advance. So, in this case, the delay they are experiencing is identical, and equals to (time left in the frame window before bulk packet is sent)+125+delta ms. However, if C is the one scheduling actions, as you suspect, then in the A->B case: A keeps spamming C with actions as soon as they are issued (A doesn't know when they are going to be scheduled, so he can't send them in bulk*). When C decides that the time's up for the frame for which actions are currently being gathered, this frame is scheduled to happen at max(25,100)+delta ms from "now", so that both A and B receive it in time. So for A nothing has changed vs. the dumb relay version, as the total delay is: 25+(time left in frame window)+max(25,100)+delta ms. But for B->A, things are looking differently: it is 100+(time left in frame window)+max(25,100)+delta ms, which is more than in the case of a dumb relay. The "scheduling relay" approach sounds plausible, but what are the advantages to this? We increase the delay for the player on a worse connection, but what do we gain? Besides, is there a way to check if this is really how SC2 works? * This definitely can be overcome, but that's irrelevant. | ||
|
Fawkes
Canada1935 Posts
https://docs.google.com/spreadsheets/d/sdfhdsjfdsjkfs/pubhtml?widget=true&&single=true&gid=0 What is the term used to describe the values after the ? (such as widget, single, gid etc...) I'm trying to figure out what these are called but it slips my mind so I can then look up what is available to me when trying to embed google spreadsheets. I guess...maybe just URL parameters... | ||
|
CatNzHat
United States1599 Posts
On July 10 2014 13:33 Fawkes wrote: The word and term isn't coming to my head. https://docs.google.com/spreadsheets/d/sdfhdsjfdsjkfs/pubhtml?widget=true&&single=true&gid=0 What is the term used to describe the values after the ? (such as widget, single, gid etc...) I'm trying to figure out what these are called but it slips my mind so I can then look up what is available to me when trying to embed google spreadsheets. I guess...maybe just URL parameters... URL params, specifically GET url params. | ||
| ||
