EPTSome notes regarding SC2 networking - Page 2
| Forum Index > SC2 General |
|
asdfTT123
United States989 Posts
| ||
|
psyote
Germany15 Posts
I guess if the server does more like computing and storing lot of state it would not scale very good and require lots of ressources. What about the annoncement that there will be LAN Latency if 2 clients are in the same network? In this scenario there could not be a need for a server during the game. | ||
|
R1CH
Netherlands10340 Posts
On March 25 2010 05:55 mgj wrote: Improving Latency I just want to attach a link for the curious: http://en.wikipedia.org/wiki/Nagle's_algorithm This is actually unrelated to nagling. I didn't mention nagling at all because currently there is no way to force it on or off for a specific program and disabling nagling globally would have serious impacts to TCP performance if the application didn't expect it. Nagling can be controlled by the application via use of the TCP_NODELAY socket option. I have a program I made to analyze the benefit of nagling by tracking the amount of send calls vs bytes sent, I just played a game of SC2 and verified that SC2 does indeed disable nagling by itself. | ||
|
Skaff
United States240 Posts
I assume you would the UDP protocol or some type of connection based layer on top of the UDP protocol? The big thing with TCP is that it adds some overhead to ensure that packets sent are received. I see a RTS being a game heavly based in the player input. The actions that are made are 100% necessary to ensure the same results are happening on both ends of the connection. I will try to use an example of a RTS vs a FPS. In a FPS, obviously user input is still big. It impacts everything in the game. However sometimes lag occurs and players end up warping around. To the best of my knowledge this is the client getting forced updated by where the character "should" be relative to the rest of the players. This is also very powerful if you are the host in these games since you will know where everyone is with 100% accuracy!  In a RTS, you can have a ton of units. Generally all the commands need to be ensured that they are being sent to your peers and are arriving in the proper order. I have seen some personal RTS projects developed by some friends that had some real weak networking implementation. Either some lag would happen at some point and the game end up splitting into two different versions of the "same" game. The commands would be sent and the updates would be made based upon what was currently going on with the other clients (have to remember this is an example of a student and not a professional). All in all... I figure Blizzard knows what they are doing in this regard. I can only speculate to the reasons why because I am no expert in the network protocols or network programming. One fun read if you are interested about some "high concepts" of TCP vs UDP can be found here (http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/). | ||
|
VTArlock
United States1763 Posts
+1 for I love r1ch | ||
|
theqat
United States2856 Posts
| ||
|
mgj
191 Posts
R1CH: I have a program I made to analyze the benefit of nagling by tracking the amount of send calls vs bytes sent, I just played a game of SC2 and verified that SC2 does indeed disable nagling by itself. Cool, had no idea. Disregard my link everyone. Skaff I'm not sure you understand who R1CH is R1CH is obviously a clever guy, but i really dont agree with this mentality. If you disagree with him, why hold back because of his status on the site? He seems like a reasonable guy, the worst thing that could happen is a good discussion where both parties end up understanding the issue better. edit: Need to figure out how to include usernames in quotes =P | ||
|
stenole
Norway868 Posts
| ||
|
mgj
191 Posts
| ||
Excalibur_Z
United States12235 Posts
On March 25 2010 06:31 theqat wrote: Skaff I'm not sure you understand who R1CH is I know who he is (goony goon goonerson) but that doesn't necessarily make him 100% right. Skaff brings up some good points that, while admittedly already addressed in R1CH's post, have some merit. By the way, Skaff, SC supported UDP so to some extent it's the application's management of the netcode that matters as much as the protocol you decide to use. | ||
|
R1CH
Netherlands10340 Posts
On March 25 2010 06:36 stenole wrote: If you use UDP, you won't just send the same information as with TCP and expect it to work. You would program your own network code to deal with acknowledge and resending packets in order to get information there as reliable as possible while still keeping within set deadline limits. Exactly right. If a packet containing a position update was lost, why wait and retransmit it if the next update contains a new transmission? If a unit command is lost, with the right coding you can isolate that very quickly and in fact retransmit faster than if it happened with TCP. UDP also performs better when data bursting since you don't run into issues such as the send or receive window sizes. You can have packets arrive out of order and reassemble them and even make use of partial date without waiting for the other fragments. UDP essentially lets you build your own protocol with exactly the amount of reliability and features you need rather than being confined to the features of TCP. Skaff I'm not sure you understand who R1CH is I don't like this attitude either, I'm not perfect - I thought SC2 used UDP until very recently when I bothered to actually get some packet analysis done. I can and will be wrong and it's important to question things. | ||
NonY
8748 Posts
| ||
|
Jsanko
Slovakia120 Posts
| ||
|
Marradron
Netherlands1586 Posts
| ||
|
Marradron
Netherlands1586 Posts
could it be that blizzard is only doing the server thing for Beta so they can gather all data from games and basicly have acces to all replays ? | ||
|
ven
Germany332 Posts
On March 25 2010 05:00 R1CH wrote: "Drop hacks" / Lag Since other players also connect to Blizzard's server, not you, there is no way to be "drop hacked" in SC2. Drop hacking involves terminating the connection to the other player via some means - trivial in BW since both players are connected to each other - desynchronize the connection and you get a drop. However in SC2, since you are only connected to Blizzard's server, not the other player, the most you can do is disconnect yourself from the server, causing you to drop. Since the server knows who disconnected, it can award the win to the remaining player. Note that this does not preclude any bugs in SC2 that might allow someone to purposefully cause a drop condition by sending malformed packets that crash the server (thus dropping everyone), but given the server architecture, drop hacking should not be an issue in SC2 provided the servers are reliable and well-coded. There should be a little bit more emphasis on the second paragraph. Warcraft 3's Battle.net worked the same way and they had a lot of issues with disconnect hacks and even crash hacks. Some of which got fixed only very recently. While it's a lot harder to do with a client/server architecture and Blizzard probably learned a lot from Warcraft 3, I don't think it's as safe as you make it sound. | ||
|
Adeeler
United Kingdom764 Posts
Map Hacking, yes it "can" be a complex issue but no it is far easier to program in extremely extremely difficult to decode data containing all the data about things in a game then non-programmers understand. Something may sound complex to the layman but usually its so simple when you get down to the actual coding its shocking its not been sorted before now especially given Blizzards ambitions for SC2. | ||
|
R1CH
Netherlands10340 Posts
On March 25 2010 07:24 ven wrote: There should be a little bit more emphasis on the second paragraph. Warcraft 3's Battle.net worked the same way and they had a lot of issues with disconnect hacks and even crash hacks. Some of which got fixed only very recently. While it's a lot harder to do with a client/server architecture and Blizzard probably learned a lot from Warcraft 3, I don't think it's as safe as you make it sound. I would hope they have proper input validation figured out by now, it's not rocket science. | ||
|
calcarus
Australia103 Posts
 | ||
|
DeCoup
Australia1933 Posts
| ||
| ||
