EPTSome notes regarding SC2 networking - Page 8
| Forum Index > SC2 General |
|
warcode
Norway46 Posts
| ||
|
space_yes
United States548 Posts
On April 28 2010 01:13 R1CH wrote: If it was true P2P like Brood War, that may be the case. But it's routed P2P, meaning all data travels through Blizzard's server first to overcome NAT and other issues. It's the same model used by War3. Great. | ||
|
Grhym
177 Posts
| ||
|
NuKedUFirst
Canada3139 Posts
yay thats what i like to hear | ||
|
NicolBolas
United States1388 Posts
On April 27 2010 08:07 R1CH wrote: After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing  .Why is this disappointing? For a game that is primarily played 1v1, Peer-to-peer is the correct networking method. And for an RTS involving hundreds of units, it is virtually a necessity. The FPS-style of client-server requires sending the state of the world (as each client sees it) to each client. For an FPS game, you may have, what, 60 entities in question? Most of these entities have only a type, a position, an orientation, and a velocity vector. Only character entities have more involved data (what weapon they're holding, etc). In a StarCraft-style RTS, you can easily have hundreds of entities, and they're all doing something. If you try to optimize this by only sending what the client needs to see at any particular time, what happens when the client jumps from looking in their base (a static scene) and goes into a battle involving hundreds of Zerglings and so forth? You'd blow your packet size trying to send all that data in a short space of time. Networking is just one of those systems that you have to design around worst-case. And for an RTS like StarCraft, P2P handles the worst case the best. P2P is a much more reliable method for such circumstances. I can't say I like the "routed" bit, as that introduces "unnecessary" latency into the mix. That still doesn't explain why Blizzard opted for TCP/IP instead of UDP/IP though. | ||
|
prOxi.swAMi
Australia3091 Posts
On April 27 2010 08:07 R1CH wrote: After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .So how come I still get terribad latency when I play against other Australians? Is this latency forced by bnet to ensure 'smoother' play? Or do you think it's a result of their choice of TCP instead of UDP? | ||
|
DeCoup
Australia1933 Posts
On April 28 2010 16:04 prOxi.swAMi wrote: So how come I still get terribad latency when I play against other Australians? Is this latency forced by bnet to ensure 'smoother' play? Or do you think it's a result of their choice of TCP instead of UDP? Both of those problems only effect people who live closer to the servers than us here in Australia. The reason you are getting this lag is that even if you are playing against someone in the same house all the data is being send From you to your friend via the US b.net servers. The 250ms latency does not even come into play because unless you are using a proxy (which gets you to 200-350) you will have 300-750ms to the servers anyway (depending on your provider). | ||
|
prOxi.swAMi
Australia3091 Posts
But anyway, I hate how Blizzard had to do this to cater for noobs who can't configure their router. Hell, these days most ppl's routers are very easy to forward ports for games. | ||
|
givemefive
United States300 Posts
| ||
|
pheus
Australia161 Posts
On April 28 2010 15:58 NicolBolas wrote: Why is this disappointing? For a game that is primarily played 1v1, Peer-to-peer is the correct networking method. And for an RTS involving hundreds of units, it is virtually a necessity. Blizzard's implementation is disappointing. I play 1v1 with my mate who lives about 15 minutes drive away and I still get 0.5 - 1s lag when issuing commands because the data has to go all the way to America and back | ||
|
Speno
Australia1 Post
Think of the infrastructure blizzard already has setup for wow, the amount of bandwidth and server farms currently setup for wow. Then look at an 'independent' game developer selling a game for $30 once off, S2 games overcome all these problems. Eliminated map hacking completely (first rts engine I have seen do it, there were map hacks out early in beta, they tweaked netcode so only visible ents are sent). Fixed random dropouts by allowing reconnections. Only server lagging causes delays, not players. No fixed worst case latency. Replays are all stored on the S2 servers along with full game stats, and any GameID can be downloaded by anyone and viewed. This routed p2p architecture is just plain old cheap, even though client server has been proven to be far superior even for RTS games, blizzard want to stick with old faithful because it’s what they know. "The next limitation is that in order to ensure that the game plays out identically on all machines it is necessary to wait until all players’ commands for that turn are received before simulating that turn. This means that each player in the game has latency equal to the most lagged player." - Gaffer on Games And TCP over UDP... It simply comes down to the reliability layer, TCP offers only one solution to lost / out of order packets, wait until we get packet 1 before we even show the receiver packet 2. This may seem like the best option, but in a continuous world simulation the newest packet of say positional data of a unit is the only thing that matters. If the sender sends: [packet1: x:1 y:2 time: 1] [packet2 x:4 y:4 time 2] And packet one gets lost in transmission, packet 2 gets received, do we care about packet one anymore? No, packet 2 contains the most up to date information about position and therefore packet 1 can be discarded. Under UDP packet 1 can be discarded, but TCP will hold back packet2 not allowing the receiving software to access it, while waiting for packet 1, it will send back the ACK for packet 2, the sender will realize packet 1 didn’t get to its destination, and resend it. Once the receiver gets packet 1, it will then feed the ordered packets to the receiving software. All the while the receiving client had more up to date information waiting for it, but tcp wouldn’t give it up. This usually is not how constant changing information is transmitted however. To save data FPS engines usually send delta compressed frames (only sending how much each value has changed since the last acknowledged state), But the principal is the same, the sender only delta compresses off the information it knows the receiver already has. This all may seem like it wouldn't provide that much benefit, and blizzard knows what they are doing. Why are we all here, because the SC2 netcode sucks. Things like a custom reliability layer with NAT punch through on top of UDP, implementing delta state compression and client side prediction for and RTS engine with support for 100s of entities with complex state can be achieved by me, a hobby game developer with no game industry experience and nothing but access to http://gafferongames.com/ And the open source version of the Q3 engine. Why can’t blizzard, a multibillion dollar enterprise with 5k employees stop taking the lazy lockstep p2p approach and stop living in the early 90's Carmack paved the way for good multiplayer games! His methods are freely accessible on the net. | ||
qartar
9 Posts
As far as map hacking, it shouldn't be difficult to simply encrypt the network data with a negotiated cypher (instead of a static cypher like what is used in their data files). Oh hey this is a month old. | ||
|
SichuanPanda
Canada1542 Posts
| ||
|
Piski
Finland3461 Posts
| ||
|
NicolBolas
United States1388 Posts
This routed p2p architecture is just plain old cheap, even though client server has been proven to be far superior even for RTS games, blizzard want to stick with old faithful because it’s what they know. Peer-2-peer unquestionably produces the best latency possible over the network. P2P isn't the problem; for a game that is primarily played 1v1, it is a great networking mechanism. The routing of the P2P networking is the problem. Client/server may solve map-hacking, but at what cost? Sure, you can have reconnection, but that's not exactly useful for a StarCraft-style RTS is it? P2P is the right networking model for SC2. It simply is not well-implemented, in part due to the routing. Things like a custom reliability layer with NAT punch through on top of UDP, implementing delta state compression and client side prediction for and RTS engine with support for 100s of entities with complex state can be achieved by me, a hobby game developer with no game industry experience and nothing but access to http://gafferongames.com/ And the open source version of the Q3 engine. Really? Prove it. Prove that you won't have to break one packet into more than one simply by Com-Scanning a 50+ Zergling army, thus inducing terrible latency. Prove that even in degenerate cases, in the worst-case scenarios, that you will not get latency problems. P2P is, pound-for-pound, as consistent as it gets. Consistency, even if it's consistently 150ms, is still better than inconsistency for a competitive RTS game. | ||
|
snpnx
Germany454 Posts
On May 24 2010 13:27 Speno wrote: Why are we all here, because the SC2 netcode sucks. Things like a custom reliability layer with NAT punch through on top of UDP, implementing delta state compression and client side prediction for and RTS engine with support for 100s of entities with complex state can be achieved by me, a hobby game developer with no game industry experience and nothing but access to http://gafferongames.com/ And the open source version of the Q3 engine. Why can’t blizzard, a multibillion dollar enterprise with 5k employees stop taking the lazy lockstep p2p approach and stop living in the early 90's Carmack paved the way for good multiplayer games! His methods are freely accessible on the net. I do think implementing this in UDP is much more difficult than it would seem to you right now. Remember that you have to be able to scale up to a 4v4 FFA. I seriously doubt that it would be "easily" implementable under such conditions. Also as Rich it was already mentioned, don't forget "unpredictable actions like scans. I simply doubt that it is easily achievable do do these transfers without notable latency variations, especially given 4v4 games. As for P2P vs C/S, routed P2P is pretty much the same as C/S for us SC2 players. We get no real benefits which are normally associated with P2P (fast transmissions without going over server), latency wise, and Blizzard keeps all strings in hand, control-wise. I do hope that they choose this design not only to counter piracy but also to be able to detect hacking better. | ||
|
One.two
Canada116 Posts
| ||
|
Piski
Finland3461 Posts
On June 27 2010 07:24 One.two wrote: Lol this is so out of date... why did someone bump it months later... didn't Blizz even switch it to UDP now. Yea this is few months old thread so dont know why someone bumped it up but I guess the theory still holds, even as now its udp. | ||
|
StalinRusH
United States734 Posts
| ||
|
ataryens
Iran213 Posts
I'm at work (which happens to be a University) and I can't play due to lag. I can enter battle.net super fast but after that everything is slow and playing a game is impossible. (it worked very well in phase 1) Is there something new this patch or did my work somehow semi-block the game. Thanks for your help. Other info: I have tried under LAN and wireless (different networks with some similar settings and some different. For example I know P2P is blocked and I couldn't download patches here in phase 1. | ||
| ||
