|
Since I see a lot of misinformation flying around, here's some brief information about SC2 and how its networking works.
UPDATE: Note that when I refer to latency in this post, I'm meaning network latency over the wire. Starcraft 2 includes a built-in command buffer that also adds input latency to smooth out and jittering or higher ping players - no amount of tweaking will reduce or alter that.
UPDATE 2: After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing . Irrelevant portions of this thread have been struck through.
UPDATE 3: Most of this thread is no longer relevant as this was written during the beta. The actual release uses UDP for game data so it has no issues with TCP latency.
Architecture Stacraft 2 games run using a server, similar to HoN - not peer to peer as the original BW does. This means that Blizzard is the one hosting the games, not you (note: custom games were not tested). The protocol is TCP, not UDP. I'm unsure why Blizzard decided to go with TCP/IP, since latency is generally worse over TCP especially with regard to lost packets. Perhaps they didn't want to deal with fragmentation or NAT issues?
"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.
You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares?
Port Forwarding Since Starcraft 2 does not use peer to peer connections, you do not need to open any ports to play nor will doing so "improve" your connection. You connect to Blizzard's server, much like you connect to teamliquid.net every time you click a link - you do not need to open ports for outgoing connections.
Map Hacking Please keep in mind this is not a thread to discuss map hacking in, just some technical commentary. As some people have argued, since SC2 uses a server, it should be possible for the server to eliminate map hacking by only sending unit data for what a player can currently see. Theoretically, this could work - however as many have pointed out, SC2 is a lot more complex than other games such as HoN that do this - in HoN, there is a very small amount of units you have to consider, with only a few of those (heroes) having any particular state. With SC2, there can be hundreds of units, each in many states. If someone moves into your fog of war with hundreds of units that your game doesn't know about, that will result in a large amount of data required to be sent to your client. TCP doesn't burst particularly well, and if one of those packets in the burst is lost, you have a significant delay. There is also spells such as Scan that reveal part of the map immediately on clicking, which the server has no way to predict you using.
While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to...
Improving Latency As I've mentioned, SC2 uses TCP. TCP is designed for data transfer with latency as a secondary consideration to bandwidth, so isn't really ideal for real-time games. Almost every FPS game in existence uses UDP for this reason. TCP requires reliable delivery - if a packet is lost, it has to be retransmitted, stalling the rest of the data while this happens. There is a small tweak you can make to improve TCP responsiveness for gaming.
Change TcpAckFrequency to 1:
How Run registry editor (Start, Run, regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. You will see a list of random looking keys, find the one that has the "IPAddress" value that matches your current IP. Right click on the right side and go New -> DWORD. Call it TcpAckFrequency with a value of 1.
Why this works Usually TCP delays sending acknowledgments of received data until either more data has been received OR a timeout period elapses. This timeout period may be because the sending side is waiting for the ack before sending more data. By setting TcpAckFrequency to 1, you send an acknowledgment immediately rather than waiting, preventing miniature "stalls" in the data stream. Note that this WILL reduce your bandwidth, as you will be sending more ack packets, thus using more network resources.
Things that MIGHT help If you use ADSL, your connection may use interleaving which is a method of error resistance that adds latency to your connection. Look in your ADSL modem settings for an option to turn it off. Note that this may increase the chances of line noise affecting your connection, so it might be required to be on. You may need to contact your ISP as it may be something controlled on their side, but don't expect them to be too accommodating.
Wired vs wireless: A properly configured wireless network should have minimal latency, however if you are in a crowded area with obstructions and other 2.4 GHz noise, the latency caused by retransmissions might add up and cause issues. Try pinging your router - your latency should be 1-2ms at most. If not, try a wired connection while gaming.
If you have a low quality wireless card (common in cheap desktop / laptops), you may experience random periods of lag while it switches frequencies for background scanning (used for roaming between access points). You can turn off background scans with a tool such as WlanOptimizer (Vista / 7 only).
Tweaking your RWIN (Windows XP only) may help - see any number of guides online regarding this.
Things that will NOT help There is a huge amount of useless information on the Internet that offers supposedly improved performance. The following will NOT improve your network quality at all: Opening your ports. Changing "TCPNoDelay" registry setting. Changing "NetworkThrottlingIndex" registry setting. Changing "TcpDelAckTicks" registry setting. Disabling "QoS Packet Scheduler". In fact, very few registry tweaks will help - there's usually a good reason defaults are the defaults.
|
|
On March 25 2010 05:00 R1CH wrote: Improving Latency Change TcpAckFrequency to 1: <div style="margin-left: 32px"> How Run registry editor (Start, Run, regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. You will see a list of random looking keys, find the one that has the "IPAddress" value that matches your current IP. Right click on the right side and go New -> DWORD. Call it TcpAckFrequency with a value of 1.
Those of us that played wow noticed this a few years ago as well, I went from ~200ms ingame to around 50ms. I do it manually in regedit but for those that are less used to tinker around in the regedit here's a simple program that fixes this for you regardless of win os: http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html
(it has nothing to do with wow, just happens to be hosted on a wow related site)
|
So what exactly does the TCPAckFrequency setting do? Does it have something to do with window size?
Edit: Nvm, you explained it.
|
United States12175 Posts
Great analysis R1CH. Although SC2 uses the "routed peer-to-peer" system, apparently similar to the one that Blizzard touted for War3, it doesn't appear that TcpAckFrequency would have any effect unless every player participating in the game had set it to the same value. Essentially, you're always playing at the speed of the slowest player, because any desyncs or delays call the Waiting for Players screen, right? The more people that know about the regkey, the better, though.
I suppose it's probably too late to expect Blizzard to restructure their netcode around UDP and simply adopt the measures for software port forwarding that War3 included.
|
Wow, thanks R1CH
Edit: TcpAckFrequency should be a hexadecimal value?
|
On March 25 2010 05:17 Excalibur_Z wrote: SC2 uses the "routed peer-to-peer" system. How do you know this? It would seem pretty flawed if this were the case, and make a lot of my points invalid .
|
I'm surprised sc2 uses tcp. That's pretty strange, but I guess the blizzard guys know what they are doing.
|
United States12175 Posts
On March 25 2010 05:19 R1CH wrote:Show nested quote +On March 25 2010 05:17 Excalibur_Z wrote: SC2 uses the "routed peer-to-peer" system. How do you know this? It would seem pretty flawed if this were the case, and make a lot of my points invalid .
Isn't that basically what you described though? Player A sends data to the server which is then sent to Players B and C, Player B sends data to the server which is then sent to Players A and C, and so forth. That is the War3 routed peer-to-peer system that Blizzard championed. I use that in quotes for SC2 because on the surface it appears quite similar, but of course it may not be.
EDIT: Although I suppose from that vague description I described what could be either routed peer-to-peer or client/server =/ Regardless, my initial question stands: wouldn't this only have an impact if every player enabled it?
|
Nice write-up. I tested the custom games and they are also routed through the server. I may also add one thing on how you can improve your latency: By getting a good add-in NIC. Best ones are the Intels: Intel PRO/1000 MT or GT(old versions) or the newer Intel PRO/1000 CT, they are very good and cheap NICs, under $30. Here are same reviews comparing it with integrated NICs:
http://forum.ncix.com/forums/topic.php?id=1304406 http://www.donutey.com/intelpro.php
Note that the Integrated NICs are evolving and difference is getting narrower but its still good to get one especially if you want to game and torrent at the same time.
|
On March 25 2010 05:26 Excalibur_Z wrote: EDIT: Although I suppose from that vague description I described what could be either routed peer-to-peer or client/server =/ Regardless, my initial question stands: wouldn't this only have an impact if every player enabled it? If it was indeed a routed P2P rather than client/server, it would indeed minimize the benefit, but it wouldn't be completely worthless since assuming both sides are data starved the same amount of time, you reduce it 50% by "fixing" it on your end.
|
On March 25 2010 05:28 Manaldski wrote:Nice write-up. I tested the custom games and they are also routed through the server. I may also add one thing on how you can improve your latency: By getting a good add-in NIC. Best ones are the Intels: Intel PRO/1000 MT or GT(old versions) or the newer Intel PRO/1000 CT, they are very good and cheap NICs, under $30. Here are same reviews comparing it with integrated NICs: http://forum.ncix.com/forums/topic.php?id=1304406http://www.donutey.com/intelpro.phpNote that the Integrated NICs are evolving and difference is getting narrower but its still good to get one especially if you want to game and torrent at the same time.
That's an interesting review, I've always thought that any NIC was enough for gaming, but there are some interesting results in that review.
|
On March 25 2010 05:28 Manaldski wrote: I may also add one thing on how you can improve your latency: By getting a good add-in NIC. Best ones are the Intels: Intel PRO/1000 MT or GT(old versions) or the newer Intel PRO/1000 CT, they are very good and cheap NICs, under $30. Here are same reviews comparing it with integrated NICs: Gonna have to disagree there, at the data rates most games use there is very little benefit to offloading. Even in the article you linked the only benefit was when maxing the connection with a torrent, and torrents are wildly erratic in speeds to begin with so I don't consider that a valid test. In any case it isn't a realistic scenario where you'd be gaming with large downloads going on in the background.
The only issue where a NIC really comes into play regarding latency is when running a server, where the amount of outgoing data begins to affect latency based on the link speed - eg 100mbps vs 1gbps. At 100mbps, you have 13107bytes/ms throughput vs 131070bytes/ms. Depending on the number of games, players, etc all hosted on the same server, this can begin to add up.
|
awesome post, i think you nailed it. BW used to have servers though back in the day, i remember all those server splits and stuff and i could always join anybody's games. It was probably more cost effective after a certain number of years to get rid of them and make it the way it is now.
|
Awsum, I wish I knew jack shit about networking =)
|
Really informative. Thanks for taking the time to explain all this!
|
Awesome post R1CH, thanks!
Improving Latency + Show Spoiler +As I've mentioned, SC2 uses TCP. TCP is designed for data transfer with latency as a secondary consideration to bandwidth, so isn't really ideal for real-time games. Almost every FPS game in existence uses UDP for this reason. TCP requires reliable delivery - if a packet is lost, it has to be retransmitted, stalling the rest of the data while this happens. There is a small tweak you can make to improve TCP responsiveness for gaming.
Change TcpAckFrequency to 1:
How Run registry editor (Start, Run, regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. You will see a list of random looking keys, find the one that has the "IPAddress" value that matches your current IP. Right click on the right side and go New -> DWORD. Call it TcpAckFrequency with a value of 1.
Why this works Usually TCP delays sending acknowledgments of received data until either more data has been received OR a timeout period elapses. This timeout period may be because the sending side is waiting for the ack before sending more data. By setting TcpAckFrequency to 1, you send an acknowledgment immediately rather than waiting, preventing miniature "stalls" in the data stream. Note that this WILL reduce your bandwidth, as you will be sending more ack packets, thus using more network resources. I just want to attach a link for the curious: http://en.wikipedia.org/wiki/Nagle's_algorithm
I've always thought that any NIC was enough for gaming, but there are some interesting results in that review. Yeah i've seen some pretty amazing results from gaming NIC's before. But honestly? I dont believe it for a second. Your ISP's peering and infrastructure is so much more important than the last router->PC connection. But hey, stranger things have happend. Someone sponsor me a gaming NIC so i can check for myself =P
Things that MIGHT help If you use ADSL, your connection may use interleaving which is a method of error resistance that adds latency to your connection. I dont know about other countries, but where i live this option is not available directly for the end-user. However, a lot of ISP's will enable/disable fast interleave if you specificly request it.
Edit: Should read posts better. You pretty much already covered what i said about interleaving.
|
Good post R1CH, I had changed TcpAckFrequency on my previous install but had forgotten about it after reinstalling recently.
|
wowowow thanks for the info!!
|
Thanks R1CH, I just did this and I am testing to see if I did it right. My IP address wasn't listed (just the one from my home router, not the one at college) so I used the old one. It was the only IPAddress file that had a number as well.
|
Great write-up, many thanks!
|
So does the server do anything more than just relaying the packets send from one client to the other?
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.
|
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.
|
I am curious what protocol you would assume SC2 could use over TCP? UDP could be used, but in general it is not considered as reliable. There is no real "connection" made and there is no sense of confirmation if packets sent have been received (or received in order). A lot of this stuff is very important when dealing with games
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/).
|
I understand absolutely none of this tech talk, but if its going to help me micro.. I'm all for it +1 for I love r1ch
|
Skaff I'm not sure you understand who R1CH is
|
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
|
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.
|
edit: Not really relevant for this thread.
|
United States12175 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.
|
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.
|
8715 Posts
Thanks R1CH. I love having some idea of how stuff works.
|
|
Rich, you claim sc2 is server based. Yet then how does AI work ? since there are hacked versions of sc2 with difrent AI ? is the server just a medium to send data from player to player ?
|
BTW another post (A)
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 ?
|
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.
|
Nice post but Blizzard need to make a blue post or something properly telling us these same things also about the drop hacks/dropping situation.
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.
|
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.
|
Interesting stuff, i wish i payed more attention in networking at uni
|
I just performed the registry change recommended by r1ch in the OP. It has reduced around half-1 second off my latency (by feel). TYVM! I'm in AU.
|
Mr. Jack gets hired by blizzard to do artwork; maybe R1CH gets hired to make SC2's netcode godly?
|
On March 25 2010 06:33 mgj wrote:Show nested quote +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. 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
both you and r1ch responded saying you didn't like my attitude but neither of you found skaff's post worth responding to I wouldn't have made that comment if his post had seemed worthwhile
|
United States7166 Posts
R1CH you have no idea how happy you just made me..
the lag is the one thing that's kept me from getting full enjoyment out of the beta.. but your Latency improvement fix has made a huge difference..feels much faster now..almost like lan latency!!
you sir are a hero!!!!!!!
|
I think that the UDP latency benefits are mostly negligible with todays broadband connections, but the biggest benefit that TCP has over UDP is congestion control and flow control. You mention how TCP has to resend data if it gets dropped, but a UDP solution would have to do the same, since this isn't a video stream where if we lose packets it doesn't really matter. UDP solutions will lose more packets than TCP solutions under network congestion because it doesn't throttle sending to account for it like TCP. I wrote a networked multiplayer asteroids-like game a few years ago, and we chose TCP for these reasons.
|
Thanks for filling us in, R1CH.
|
Thank you very much for this thread! Very useful information!
|
On March 25 2010 09:09 FrostedMiniWeet wrote: I think that the UDP latency benefits are mostly negligible with todays broadband connections, but the biggest benefit that TCP has over UDP is congestion control and flow control. You mention how TCP has to resend data if it gets dropped, but a UDP solution would have to do the same, since this isn't a video stream where if we lose packets it doesn't really matter. UDP solutions will lose more packets than TCP solutions under network congestion because it doesn't throttle sending to account for it like TCP. I wrote a networked multiplayer asteroids-like game a few years ago, and we chose TCP for these reasons.
Thats kind of the assumption I was on as well. But then again (being since I have done no heavy network code myself) you can push some extra juice out of getting the both out of both worlds.
As far far as the "not knowing R1CH" comment.. I have no issues if I can bring up a point and have it get shot down (as long as I have some kind of angle with my point). I am far from all knowing (sadly). Heck I might learn a thing or two from him as well!
|
The point of UDP vs TCP is that with UDP, you can write your own code on top of UDP to make it reliable, and since you know exactly the kinds of data that you are sending over the wire and since each packet does not have to be processed in order, you don't have to wait for out of order chunks to arrive before continuing to process incoming packets. Yes, the overall overhead of the TCP headers is almost negligible on todays broadband, but using your own reliable UDP helps prevent spikes in the case of dropped/missing TCP chunks.
Edit: Woo run-on sentence, if that's not clear let me know and I'll rephrase .
|
Very informative thread, I hope to see updates in the future as more discoveries are made regarding sc2's netcode. Thanks!
|
On March 25 2010 05:00 R1CH wrote:
Architecture Stacraft 2 games run using a server, similar to HoN - not peer to peer as the original BW does. This means that Blizzard is the one hosting the games, not you (note: custom games were not tested). Highly doubt this. Blizzard has never hosted games for a free service (WoW's pay to play obviously) because it'd cost them a ton of money to maintain, for no real reason. Can't see why they'd be hosting the games this time around.
|
how do you check your ping in game?
|
On March 25 2010 09:45 McCain wrote:Show nested quote +On March 25 2010 05:00 R1CH wrote:
Architecture Stacraft 2 games run using a server, similar to HoN - not peer to peer as the original BW does. This means that Blizzard is the one hosting the games, not you (note: custom games were not tested). Highly doubt this. Blizzard has never hosted games for a free service (WoW's pay to play obviously) because it'd cost them a ton of money to maintain, for no real reason. Can't see why they'd be hosting the games this time around.
Just because it's hosted server-wide doesn't mean that it must have a monthly fee. WoW costs a lot because it's a persistent world and MMOs tend to be extremely demanding. Just look at this link for a glance at what WoW requires.
http://www.worldofraids.com/topic/14011-austin-game-developers-conference-the-universe-behind-world-of-warcraft/
SC2 is unlikely to have a monthly fee because it would look very bad for Blizzard compared to the competition. All MMOs have monthly fees, but not all RTSs do. It's going to be a lot harder to sell a game that asks for $15 a month when there's many other games in the same genre that don't have such fees. Heroes of Newerth in particular isn't even going to cost a full $50.
|
The point of UDP vs TCP is that with UDP, you can write your own code on top of UDP to make it reliable, and since you know exactly the kinds of data that you are sending over the wire and since each packet does not have to be processed in order, you don't have to wait for out of order chunks to arrive before continuing to process incoming packets. Yes, the overall overhead of the TCP headers is almost negligible on todays broadband, but using your own reliable UDP helps prevent spikes in the case of dropped/missing TCP chunks.
Edit: Woo run-on sentence, if that's not clear let me know and I'll rephrase .
I totally understand that logic, but under good network conditions, even a custom reliable UDP implementation has negligible performance benefits when there is a constant steady flow of traffic between endpoints. re-transmission rates are very low under decent conditions, and with a constant flow of data between endpoints (which starcraft has) acks are essentially free because they ride on the backs of data that's being sent anyway. Starcraft has no need of the bursty benefits of UDP, and under poor network conditions, unless a custom reliable UDP solution also implemented flow and congestion control (which would effectively make it a TCP implementation), then network performance goes to hell very quickly. The flow and congestion control of TCP give it a graceful and steady degradation of gameplay in accordance with network degradation, without sacrificing much to UDP under good conditions. The best custom UDP implementation will be only slightly better in good network conditions, but TCP will be far superior under bad conditions. TCP is becoming more and more common in games nowadays, and its just so much easier to deal with also.
|
On March 25 2010 09:45 McCain wrote:Show nested quote +On March 25 2010 05:00 R1CH wrote:
Architecture Stacraft 2 games run using a server, similar to HoN - not peer to peer as the original BW does. This means that Blizzard is the one hosting the games, not you (note: custom games were not tested). Highly doubt this. Blizzard has never hosted games for a free service (WoW's pay to play obviously) because it'd cost them a ton of money to maintain, for no real reason. Can't see why they'd be hosting the games this time around. Diablo 2?
|
Just a little bit of feedback.
I'm a college student living on campus at the moment, and that sounds bad at first but we actually have pretty insane internet that is pretty consistently around 17mb/s down (sometimes ridiculously more) and 5mb/s up. Downloads are almost instant, pings are always low, and everything really just works great.
Until the StarCraft 2 Beta. Between ~2pm and ~2am EST I just get insane amounts of lag on Bnet 2.0, as does my roommate and my friend (whom many of you may know) Whiplash who lives in the same tower as myself and my roommate, just a few floors up. SC2 Beta seems to be the only game that causes problems as (don't cringe at the list of games I'm about to reel off xD) Dawn of War 2 and by extension Games for Windows Live work perfectly fine during that period, server-based FPS games (I wouldn't happen to know if P2P crap like Modern Failfare 2 and such work as I try to avoid those), Demigod (uses some proxy servers hence why I bother mentioning it), Brood War's Bnet, ICCUP, WC3 Bnet, etc... all work fine during that time and all others.
Long story short, myself, my roommate, and Whiplash tried the recommended tweaking of Acks and found no improvement in the crippling lag and disconnects. I'm not really sure if it got worse as although we were getting worse, choppier lag, it was also later in the day (seems to get worse up until like 11pm and then it gets better).
Not really asking for help as technically our internet is filtered through the campus network and so ostensibly there could be something funky going on there (would be weird considering that literally nothing else has such an issue with that) and/or it's some odd issue on Blizzard's end, just figured I'd report on the results of attempting to use the suggested solution in the hopes it might be useful somehow (shrug).
|
Mystlord
United States10264 Posts
Nice writeup R1CH! Your posts always remind me how little I actually know, but in a good way.
|
On March 25 2010 09:47 _rdm_ wrote: how do you check your ping in game?
Hello RDM,
I'm not sure how the pros would do it but any packet sniffer would do. Personally, I would use WireShark but this isn't my area of expertise.
Edit - forgot to pay my respects to R1CH. Fantastic write up. You have a knack for taking complex problems and presenting them in plain English.
|
On March 25 2010 10:00 R1CH wrote:Show nested quote +On March 25 2010 09:45 McCain wrote:On March 25 2010 05:00 R1CH wrote:
Architecture Stacraft 2 games run using a server, similar to HoN - not peer to peer as the original BW does. This means that Blizzard is the one hosting the games, not you (note: custom games were not tested). Highly doubt this. Blizzard has never hosted games for a free service (WoW's pay to play obviously) because it'd cost them a ton of money to maintain, for no real reason. Can't see why they'd be hosting the games this time around. Diablo 2? Diablo 2 doesn't have a persistent world like WoW does, so most of the network code is offloaded on the players. It's much easier to keep track of inventories than it does to run a few thousand mobs.
|
On March 25 2010 10:26 Zanno wrote: Diablo 2 doesn't have a persistent world like WoW does, so most of the network code is offloaded on the players. It's much easier to keep track of inventories than it does to run a few thousand mobs. By your own argument, SC2 has even less to keep track of - no persistent state to consider. None of the D2 netcode is "offloaded", all players connect to the Diablo 2 game server - it isn't a routed P2P system. Teleporting through several levels in Hell in D2 will generate more units than a typical SC2 game.
|
I have one question:
Is there any way to check my latency ingame, so i can check if its better after r1ch's help? :D
Awesome thread r1ch btw ! Your great !!!!
|
R1CH godly as usual. Thanks
|
Wow, even in-game play is server based. Blizzard is serious about keeping total control of the game in their hands. Not that it ever works with clever people always looking to circumvent controls.
But on a different note, Blizzard then should have massive amounts of gameplay data - if they analyze it correctly they can then see what strategies work and dominate, and which ones don't. Which units are used more often by players that win, etc. Which maps are more favored for races in various matches than others. And they'll also know at what time of day you play online, every day, but oh well.
I'm puzzled they're using TCP. Oh well to that, too.
|
R1ch....what do you do for a living besides helping people?
|
On March 25 2010 10:46 R1CH wrote:Show nested quote +On March 25 2010 10:26 Zanno wrote: Diablo 2 doesn't have a persistent world like WoW does, so most of the network code is offloaded on the players. It's much easier to keep track of inventories than it does to run a few thousand mobs. By your own argument, SC2 has even less to keep track of - no persistent state to consider. None of the D2 netcode is "offloaded", all players connect to the Diablo 2 game server - it isn't a routed P2P system. Teleporting through several levels in Hell in D2 will generate more units than a typical SC2 game. I don't think anyone should argue how d2 works to R1CH.
Thanks for the info bro, excellent posts per usual~
|
I just wanted to point out the fact that stating that there is no way to drop hack with the current SC2 multiplayer architecture is incorrect. I'm not saying drop hacking is happening, I'm just giving my opinion (and knowledge) as an informatics security expert.
I can assure you there are ways to bypass the Blizzard servers so that you can send through a carefully crafted packet that will execute whatever you want in the remote client... or, in this case, crash him. These flaws are not easy to find, but they are always there
So don't take for a grant that there is no way to do something like a drop hack sometime in the future.
|
Ah I was hoping there was a simple way to check latency in the beta client
|
I don't have the game. Could anyone upload a wireshark cap to look through? Then we could get a better idea of what is actually going on. For those capping: it'd be nice if you could start capturing BEFORE you start up SC2, so that we can get an idea about how the auth gets set up and the packets are routed after you join a game.
It wouldn't surprise me if chat went through the server, and the game data was routed, which might give the impression of alot of TCP -> server chatter.
Naturally all this is speculation until we actually get a packet capture...
|
The final release is supposed to support offline/LAN play once you've authed with the B.net servers though, right? There was a poster earlier in the thread who suggested the perpetual B.net server involvement might be a beta-only thing -- I'm wondering whether he's on to something. I don't see why they'd use a centralized server for B.net games if they have to have the server code present in the client for LAN games anyway, other than automatic replay/stats capturing like someone mentioned above.
I'm also very puzzled by their choice to use TCP for the game protocol, even with nodelay. For one thing, if they were using UDP they would have the option of using the B.net server as a rendezvous server for NAT traversal, the way some people already do for BW when they host a game and then leave once it's started.
R1CH, would you mind elaborating a bit on how you came to the conclusion that the game data transport is TCP through the B.net server? I'm not doubting you, it's just my inner scientist wanting to double-check your reasoning ^^
|
On March 25 2010 14:40 tarpman wrote: R1CH, would you mind elaborating a bit on how you came to the conclusion that the game data transport is TCP through the B.net server? I'm not doubting you, it's just my inner scientist wanting to double-check your reasoning ^^
I'm not R1CH, but if you run a packet sniffer (logger) like tcpdump or Wireshark while playing the game, you can see what packets are coming to and from your computer. If the game data is sent in packets with TCP headers...it's using TCP.
And how do you tell what information is the game data? That might be tricky, but I suspect that if you don't see any UDP packets and instead are seeing only TCP packets, you might make a conclusion based on that.
|
On March 25 2010 14 Myrmidon wrote:Show nested quote +On March 25 2010 14:40 tarpman wrote: R1CH, would you mind elaborating a bit on how you came to the conclusion that the game data transport is TCP through the B.net server? I'm not doubting you, it's just my inner scientist wanting to double-check your reasoning ^^ I'm not R1CH, but if you run a packet sniffer (logger) like tcpdump or Wireshark while playing the game, you can see what packets are coming to and from your computer. If the game data is sent in packets with TCP headers...it's using TCP. The chat probably IS the auth. I.e. you HAVE to stay connected to the chat to be connected to the game. Thus; routed game + auth, right?
What to look for: If it IS all TCP traffic, look in the header to see where the destination address is after authentication. Join a game with someone who's IP you already know and check the destination addresses. If his IP is showing up, then it's p2p.
|
Undead_Knight you're right. To say something is full proof in today's world is a strong statement. I believe the message stated was it's really hard to drop hack someone where as in the past it was relatively easy.
|
I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit?
|
R1CH once again is amazing!
|
|
am I the only one who thinks R1CH should be working at blizzard or something ?
|
I read that the registry tweak works in XP with no problems but it doesn't have an effect in Windows 7, can anyone confirm this?'
EDIT: It seems just as many people claim that it DOES have a positive effect on Windows 7... I don't know who to believe!
|
You are awesome man! Thanks for the in depth post.
|
Thanks for the information R1CH!
On March 25 2010 15:34 Xeris wrote: am I the only one who thinks R1CH should be working at blizzard or something ?
Forget it. We need him at Teamliquid!
|
|
On March 25 2010 15:14 Psyonic_Reaver wrote: I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit?
I would love to know this as well <3
|
nice analysis/testing. im gonna bookmark this page... for future reference : ) i might be able to understand more next time lol
|
Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in?
|
On March 25 2010 17:48 Shauni wrote: Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in?
Usually the folder with the MOST stuff is the right one.
|
On March 25 2010 18:05 Qiin wrote:Show nested quote +On March 25 2010 17:48 Shauni wrote: Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in? Usually the folder with the MOST stuff is the right one.
http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html
Just run that script. Very simple, easy to use, easy to remove etc.
|
On March 25 2010 15:14 Psyonic_Reaver wrote: I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit? I'm on windows 7 64 bit and I chose the DWORD (32-bit) option and it worked fine.
|
R1CH you are such a baller.. I hope you get a job at Blizzard.
|
On March 25 2010 19:04 SoleSteeler wrote:Show nested quote +On March 25 2010 18:05 Qiin wrote:On March 25 2010 17:48 Shauni wrote: Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in? Usually the folder with the MOST stuff is the right one. http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.htmlJust run that script. Very simple, easy to use, easy to remove etc.
For a computer/registry nooby such as myself, is this safe?
|
sort of off topic but: Hey rich just a question, what's your SC2 name? (I'm assuming you're in the beta)
|
that TCP fix to reduce latency will probably be extremely useful to lots of people.
Bookmarked this thread in case i run into high latency in the future.
|
On March 25 2010 22:39 FortuneSyn wrote:Show nested quote +On March 25 2010 19:04 SoleSteeler wrote:On March 25 2010 18:05 Qiin wrote:On March 25 2010 17:48 Shauni wrote: Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in? Usually the folder with the MOST stuff is the right one. http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.htmlJust run that script. Very simple, easy to use, easy to remove etc. For a computer/registry nooby such as myself, is this safe?
Yes, it's from one of the biggest and most trusted WoW interfaces sites on the internet. All it does is add the stuff to your registry for you. Almost 400,000 people have downloaded it. And it comes with a remover and checker to make sure it's working. Very easy, I just did it myself. Big difference.
|
Leatrix Latency Fix also has the option for you to DISABLE the registry edits, so its a pretty handy thing to have somewhere on ur comp if you ever decide u want your default settings back.
|
though I dont have a beta key that was very informative, thanks sir...
PD: love your actitude about knowing the fact that you can be wrong...
|
Rich pisses sockets, and for that we love him.
|
Thanks R1CH for this thread.
I think blizzard made a mistake when opting for TCP, but they'll surely prove me wrong anytime soon! ^^ Their servers might need a lot more CPU power to deal with the overhead generated from soooo many (established) connections.
Let's hope for the best!
|
Kyrgyz Republic1462 Posts
Why is everyone bashing TCP? Have you ever tried to make SC1 work in a slightly non-trivial NAT setup (e.g. some people playing from inside the LAN having shared external IP and other people playing form outside)? Screw that, really.
Incidentally, I don't quite understand why Blizzard insists on having a fixed worst-case latency value (I remember they mentioned that setting this to 250ms was an overkill). In SC1, this value could be set in-game (low latency, high latency, very high latency). Why cannot it be automatically adjusted during the game to suit both players' connections?
|
|
United States12175 Posts
On March 25 2010 19:10 DeCoup wrote:Show nested quote +On March 25 2010 15:14 Psyonic_Reaver wrote: I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit? I'm on windows 7 64 bit and I chose the DWORD (32-bit) option and it worked fine.
From what I understand, on Win7, TcpAckFrequency is set to 1 by default. For those using Vista, I believe you need to have at least SP1 (or the deployed hotfix) before it will take effect.
|
Awesome R1CH, so what are the chances that these things get fixed before the end of beta and for all of battle net.
|
I thought so. Groups not to be named who are trying to run multiplayer without beta keys are having fits getting it to run since they need to decode packets for every troop type and action. If all they had to do was emulate a handoff after which the clients communicated directly with each other they'd have a lot less to do. Their methods and difficulties led me to believe that all communications did indeed go through Blizzard, and R1CH's post bears that out. It was also hinted at earlier in that thread about latency.
No LAN mode here, even if you are on the same physical LAN. I don't see that going over so well. Also I wouldn't count on seeing ICCUP for SC2 any time soon, though if Bnet is good enough who cares. Except one could say that by routing all packets through itself it isn't good enough. We'll see. I certainly haven't noticed any terrible lag issues while playing beta, but I am not very high level.
|
|
I love your posts R1CH. You always share such insightful information. I truly appreciate it.
If I was as leetskeet as you I'd totally hack TL and steal your icon !
|
I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit?
using a DWORD or a QWORD in the registry has nothing to do with the cpu architecture. The registry is like a simple database, and a DWORD or QWORD is just the size on disk that the field will occupy. This would only become a problem if the value is too large to fit in the DWORD, and the program reading the registry truncates the QWORD value by casting it to a DWORD. Stick with DWORD, since that is the size of the field that is expected.
|
I'm going to go out on a limb here and say DWORD = Double (2x16 = 32) and QWORD = Quadruple (4x16 = 64) given that you're storing one bit (0 or 1) I think both options are just fine :-)
|
awesome, thanks R1CH! you're a beast
|
How much truth is there in this post? (Taken from bleepingcomputer forums)
Setting the TcpAckFrequency may improve your apparent ping but will not improve your actual network speed. If anything, it may make it worse by increasing the number of actual packets being transmitted by your machine for the same amount of data.
When a computer connects to another computer using TCP it performs what is known as the TCP Three-way Handshake. what happens is this:
1. Client computer sends a SYN (synchronize) packet to the server computer 2. Server computer sends a SYN-ACK (SYN-acknowledged) packet to the client computer 3. Client computer sends a final ACK (ACK acknowledged packet to the server computer.
Thus begins the TCP connection.
All these SYN, SYN-ACK, and ACK packets carry no actual data. The Windows network stack, since Windows 2000 has, by default, only responded to every other TCP SYN packet unless additional data packets are not received within a specific period of time (per RFC-1122). This reduces the total number of non-data packets that must be sent. Changing the referenced registry value to 1 will cause Windows to respond to every SYN packet, thus doubling the TCP overhead for a connection. While this will likely improve the "ping" rating you get in online games (since it takes a SYN packet less time to be ACKed) it will not increase the actual speeds of data transfer but reduce it.
|
As far as I know (granted, I have no idea what the actual Windows networking stack does), the above is correct I think? I don't know the exact details.
As R1CH said in the first post and the blurb you quoted reiterates, increasing TCPAckFrequency will increase the overhead associated with a connection because it increases the number of non-data packets that are sent. Adding in these extra non-data packets reduces the amount of actual data packets that can be delivered, which reduces your potential max bandwidth.
For our purposes, we want to reduce TCP latency at the expense of bandwidth. Lower latency is better. Essentially, there's a tradeoff involved, and the default setting is geared towards what is best for most people. We're tweaking the default setting to get better performance in our particular game scenario because bandwidth is not a concern for us.
edit: to be a little more accurate (but R1CH already explained it), increasing the ACK frequency just reduces the latency in the case that a TCP packet was lost. By requiring more ACKs, you find out sooner if a packet was lost, so it can be retransmitted (and received) faster.
|
On March 25 2010 05:00 R1CH wrote: "Drop hacks" / Lag ... In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares?
I could be wrong, but I think I remember seeing lag screens where observers were lagging, particularly during Zotac streams. Is there a special reason for those lags or did Blizzard not actually implement observer slots the who-cares-if-they-lag way despite being rather simple to implement?
|
Thanks for the info R1CH. You are totally like a Serra Angel, no deck is complete without you.
|
Um, a semi- sc2 related question. I have a beta key from a friend, but i can't download it , ( i believe my school blocks p2p sharing ) . I tried disabling p2p and that didn't work I guess they blocked the ports for sc2 ... or something... Wondering if anyone has an idea of what i could do
|
This design sucks! A game which needs manual registry tweaking to function properly, awesome. Thats's what we expect of a multibillion dollar software firm.
The decision to use TCP when it's an industry standard to use UDP in comparable games (for obvious reasons!) is another epic fail.
And:
Why did they choose a central server with all disadvantages (bottleneck, latency) and then not make use of advantages this setup would offer (prevent maphacking etc.)?
Answer: They want to control network play, and give a shit about a good game.
|
On March 25 2010 05:00 R1CH wrote:
You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares?
Can someone kindly explain to me in detail on this? Sometimes I find games stop sometimes with this window and sometimes it stops without this window at all. So I'm wondering what's causing the second case. Note: Game wasn't paused by a player. Thanks.
|
LAN crack will be out soon (first vid out possibly tomorrow), blizz should just put it in the game themselves, instead of forcing people to hack it..
|
ok this is awesome, but are there any drawbacks to doing the ack registry thing? Sorry if this has been asked already.
|
On March 29 2010 23:55 CharlieMurphy wrote: ok this is awesome, but are there any drawbacks to doing the ack registry thing? Sorry if this has been asked already. Yes, this has been answered already. In fact, in the original post. For your convenience, it increases your bandwidth but increases your responsiveness or latency as well.
|
On March 29 2010 17:53 HeavOnEarth wrote:Um, a semi- sc2 related question. I have a beta key from a friend, but i can't download it , ( i believe my school blocks p2p sharing ) . I tried disabling p2p and that didn't work I guess they blocked the ports for sc2 ... or something... Wondering if anyone has an idea of what i could do quite offtopic, but did you try downloading the installer to a usb or external drive and transporting it over? I used my 80g ipod for stuff like this all the time. In fact I even have scbw installed with chaoslauncher on my ipod and I can plug it in and play anywhere without installing.
|
R1ch
Change TcpAckFrequency to 1:
How Run registry editor (Start, Run, regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. You will see a list of random looking keys, find the one that has the "IPAddress" value that matches your current IP. Right click on the right side and go New -> DWORD. Call it TcpAckFrequency with a value of 1.
Why this works Usually TCP delays sending acknowledgments of received data until either more data has been received OR a timeout period elapses. This timeout period may be because the sending side is waiting for the ack before sending more data. By setting TcpAckFrequency to 1, you send an acknowledgment immediately rather than waiting, preventing miniature "stalls" in the data stream. Note that this WILL reduce your bandwidth, as you will be sending more ack packets, thus using more network resources.
If i'm on a wifi router connection, do I need to find the computer IP or my network IP? So like 192.168.1.103 which would be specific , or 22.172.226.22 which would be my whole house. Also, in the case of the specific one, it seems to change from time to time for whatever reason. Will I have to change the registry setting every time as well?
In every directory, I'm seeing 0.0.0.0 for the IP , but in a couple of them I do see the DhcpIPadress value at 192.168.1.103
On March 25 2010 18:05 Qiin wrote:Show nested quote +On March 25 2010 17:48 Shauni wrote: Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in? Usually the folder with the MOST stuff is the right one. I've got 11 folders, 3 of which have a lot of shit. what kind of vague/uneducated reply is this >.<
On March 25 2010 19:04 SoleSteeler wrote:Show nested quote +On March 25 2010 18:05 Qiin wrote:On March 25 2010 17:48 Shauni wrote: Regarding the fix. I have 5 folders in the registry but every 'IPAddress' has the value of 0.0.0.0. Two of the folders however, have DhcpIpAddress set as my internal IP. How do I know which folder to add the key dword in? Usually the folder with the MOST stuff is the right one. http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.htmlJust run that script. Very simple, easy to use, easy to remove etc.
also, anyone who is having the same problems the download from this link is here http://www.wowinterface.com/downloads/dl.php?s=a7d40c29ec44de35bad9006f38adfeb7&id=13581
|
On March 30 2010 00:17 CharlieMurphy wrote:Show nested quote +On March 29 2010 17:53 HeavOnEarth wrote:Um, a semi- sc2 related question. I have a beta key from a friend, but i can't download it , ( i believe my school blocks p2p sharing ) . I tried disabling p2p and that didn't work I guess they blocked the ports for sc2 ... or something... Wondering if anyone has an idea of what i could do quite offtopic, but did you try downloading the installer to a usb or external drive and transporting it over? I used my 80g ipod for stuff like this all the time. In fact I even have scbw installed with chaoslauncher on my ipod and I can plug it in and play anywhere without installing. yea im just gonna go to my friends apartment and do this later. just wondering if anyone hosted it somewhere, not trusting any cracked stuff.
|
On March 29 2010 21:10 Metaspace wrote: This design sucks! A game which needs manual registry tweaking to function properly, awesome. Thats's what we expect of a multibillion dollar software firm.
The decision to use TCP when it's an industry standard to use UDP in comparable games (for obvious reasons!) is another epic fail. Remember that this is still beta. Assuming sensible modularity, it wouldn't be difficult for Blizzard to rework the network engine to use UDP before release.
And:
Why did they choose a central server with all disadvantages (bottleneck, latency) and then not make use of advantages this setup would offer (prevent maphacking etc.)?
Answer: They want to control network play, and give a shit about a good game. I think you might want to do some research on exactly what foolproof maphack-prevention in an RTS of SC2's scale would entail before bashing them like that. I'm pretty sure it's already been discussed in this thread.
Edit: ehh, was browsing and didn't notice the dates. Anyway, thanks R1CH for the info ^^
|
On April 02 2010 12:40 fonger wrote:Remember that this is still beta. Assuming sensible modularity, it wouldn't be difficult for Blizzard to rework the network engine to use UDP before release.
Perhaps, but keep in mind that using UDP, as has been discussed, requires constructing a sufficiently reliable Application-layer netcode for StarCraft 2 to work properly with packet loss/re-ordering/etc. Basically, Blizzard would have to write a bunch of code to handle what TCP does automatically.
However, if they do this, it would be very appreciated. At the very least they could scale the forced command lag to match network conditions.
I think you might want to do some research on exactly what foolproof maphack-prevention in an RTS of SC2's scale would entail before bashing them like that. I'm pretty sure it's already been discussed in this thread.
Although I doubt this is possible given how many machines would have to be dedicated to maphack prevention, what about threading? Why not have some independent thread be created for every Nth packet of the game, which is analyzed for map-hacking independent of the routing thread? Should one of the players be found to be map-hacking, then it is simply a matter of dropping that player.
The flaws of this are somewhat obvious, though. The most notable is practicality. Blizzard would probably require a room of computers just for checking each game for maphacking, independent of the server (some sort of RPC setup would be needed here).
|
On April 03 2010 09:00 Shadowfury333 wrote: Perhaps, but keep in mind that using UDP, as has been discussed, requires constructing a sufficiently reliable Application-layer netcode for StarCraft 2 to work properly with packet loss/re-ordering/etc. Basically, Blizzard would have to write a bunch of code to handle what TCP does automatically. It's not that bad for a company like Blizzard.
On March 25 2010 05:00 R1CH wrote: Things that will NOT help There is a huge amount of useless information on the Internet that offers supposedly improved performance. The following will NOT improve your network quality at all: Opening your ports. Changing "TCPNoDelay" registry setting.
The TCPNoDelay enables/disables the Nagle algorithm. This can be disabled dynamically by an application using winsock. SC2 probably does this automatically. You guys may want to set your TCPAckFrequency back to its default when you're not gaming if you stream lots of data and don't have a sick internet connection.
|
While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to...
Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu.
As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness.
There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security.
|
On April 04 2010 09:36 Adeeler wrote:Show nested quote +While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to... Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu. As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness. There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security. I hope you have some examples of your 'clever coding techniques' and 'infinitesimal loads' rather than just a very large amount of jargon and accusations...
Also, why has this thread gone so long without posting a single wireshark capture to back up these claims?
|
On March 25 2010 05:00 R1CH wrote:
since latency is generally worse over TCP especially with regard to lost packets.
Map Hacking it should be possible for the server to eliminate map hacking by only sending unit data for what a player can currently see.
DONT WORRY ABOUT LATENCY first sorry for my bad english let me add this:
there is no packetloss in TCP and its way more stable, if a packet isnt received it will be resent until it is received and then continue with the next one... :
Blizzard calculate the ping for both players and send delayed packet in a way that both player will almost see thing at the same time.
Even if before it was UDP, with the possibility of sending delayed packet depending on the players ping, Now the actions are going to happen more simultaneously for the players.
Instead of feeling like your computer is skipping some frames when someone is lagging, it will be much smoother.
For the maphacking issue, yea you're right sending data only if the player can see in that range.
but all the data are needed for the replays... you cannot send these data at the end of the game because you never know if a player will drop or something...
The only possible option i can see is that Blizzard would keep all the game data and send them at the end of the game if a player request the replay... but i dont know if blizzard server could handle this... would take a lot more memory and would cause a lot more traffic issue.
So personally i dont think Blizzard will do something for maphacking... game is already beta they cannot change the whole tcp architecture to only send whats in players sight + finding a solution to the replays issue that it would cause....
|
THANK YOU
|
On April 06 2010 08:19 Tyraz wrote:Show nested quote +On April 04 2010 09:36 Adeeler wrote:While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to... Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu. As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness. There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security. I hope you have some examples of your 'clever coding techniques' and 'infinitesimal loads' rather than just a very large amount of jargon and accusations... Also, why has this thread gone so long without posting a single wireshark capture to back up these claims?
/agreed
There is no explanation as to what "clever coding" is and how it would necessarily guarantee the security of the game state if a client has all of the game data at any given time (ignoring minor discrepancies from lag).
|
On April 04 2010 09:36 Adeeler wrote:Show nested quote +While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to... Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu. As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness. There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security.
This is a lot of words which say nothing
|
On March 25 2010 15:14 Psyonic_Reaver wrote: I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit? Use 32-bit.
|
On March 25 2010 05:00 R1CH wrote: . In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player.
|
On April 09 2010 20:59 Paladia wrote:Show nested quote +On March 25 2010 05:00 R1CH wrote: . In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be.
|
On April 09 2010 22:04 Hittegods wrote:Show nested quote +On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote: . In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers?
|
On April 09 2010 23:23 Paladia wrote:Show nested quote +On April 09 2010 22:04 Hittegods wrote:On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote: . In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers?
You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? The bolded part is concerning how SC2 handles lag, the italic part is relating to how HoN does it, and how it could be. Are things getting clearer?
|
On April 09 2010 23:32 Hittegods wrote:Show nested quote +On April 09 2010 23:23 Paladia wrote:On April 09 2010 22:04 Hittegods wrote:On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote: . In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers? Show nested quote +You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? The bolded part is concerning how SC2 handles lag, the italic part is relating to how HoN does it, and how it could be. Are things getting clearer? You didn't bold the part after. He claims that "this was done out of fairness". Obviously that does not apply to observers. Also, he says "Rather than allow the server to continue if one player is lagging", again, no mentioning of how it is for observers.
No where does he mention how it currently is for observers. I very much enjoy the irony of you attempting to point out flaws in others reading ability, however.
|
On April 09 2010 23:45 Paladia wrote:Show nested quote +On April 09 2010 23:32 Hittegods wrote:On April 09 2010 23:23 Paladia wrote:On April 09 2010 22:04 Hittegods wrote:On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote: . In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers? You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? The bolded part is concerning how SC2 handles lag, the italic part is relating to how HoN does it, and how it could be. Are things getting clearer? You didn't bold the part after. He claims that " this was done out of fairness". Obviously that does not apply to observers. Also, he says " Rather than allow the server to continue if one player is lagging", again, no mentioning of how it is for observers. No where does he mention how it currently is for observers. I very much enjoy the irony of you attempting to point out flaws in others reading ability, however.
Right, which is why it's only in theory, not in practice ....
|
After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .
|
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 . lol. Somewhere in the southern parts of germany, Selector screams "FUCK YEAAAH!" T_T
|
United States12175 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 .
I figured. They seemed to be pretty happy with that system in War3, and why reinvent the wheel? (That's rhetorical, obviously there are some significant benefits using a C/S system)
|
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 .
How did you find out this? I tested it and only had 2 connections coming out, one to their logon server and one to their game server, which gets initiated once i join/create a game. No other connections were going out from the computer while playing.
|
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 . maybe because of beta? war3 is client -> server, right? why shouldn't sc2 be?
|
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 that? Isn't it better for lower potential latency to be p2p?
|
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.
|
I am assuming you are talking about ladder games, because the custom games in Warcraft 3 were little more than LAN games with the internal "fake latency" variable set to 250 and posted to the list of games on battle.net. You were able to request to join a game directly if you were to send the correct packets directly to the host.
|
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.
|
I have nothing useful to add but I simply wanted to thank you for a great post.
|
On April 28 2010 06:11 space_yes wrote:Show nested quote +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.
yay thats what i like to hear
|
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.
|
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?
|
On April 28 2010 16:04 prOxi.swAMi wrote:Show nested quote +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? 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).
|
nvm i should've read further up.
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.
|
well it makes things easier for people that don't even have access to networking devices like at universities, and it makes it a hell of a lot easier to play 2v2 with your roommate when you only have 1 IP
|
On April 28 2010 15:58 NicolBolas wrote:Show nested quote +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.
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
|
You cannot argue that it would be too difficult to handle running dedicated servers for a non pay2play game.
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.
|
If you think Q3 had nice networking take a look at some of the stuff the D3 engine does. Most of the delta compression etc is visible in the game dll.
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.
|
And just a note on port forwarding. Unlike what the OP implies it most certainly WILL affect your game-play as port forwarding has absolutely 100% 0, nothing, silch, nada, zip to do with connecting to another peer or to a server. Port forwarding has to do with what ports you're allowing your computer or network to have access to. In other words if SC2 requires port 6112 for example - like most Blizzard's games have then blocking that port will degrade performance. Once again it has NOTHING absolutely nothing to do with who you are connecting to, port forwarding is a local/client side issue and in no way can be affected by who you are connecting to, only what port you are connecting on. Other than that RICH's post was accurate and some really good info there for people who are interested.
|
I never even though about that latencly trick thanks r1ch. Too bad it's peer-to-peer, or nothing wrong with peer-to-peer but that the data travels through blizzard is kinda a bummer
|
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.
|
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.
|
Lol this is so out of date... why did someone bump it months later... didn't Blizz even switch it to UDP now.
|
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.
|
wait....does this mean i wont be able to play sc2 on dialup???!?!?
|
Hello, 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.
|
Someone mentioned "Leatrix latency fix" earlier in this thread. Can anyone confirm that this actually reduces your latency for sc2? I just installed and tested it 1 game myself, but i didnt notice any difference at all. If i even got it to work that is.. Which i supposedly did.
|
|
Thx for the tip, but i dont see anything specific regarding better latency in what you linked.
|
im using leatrix as well.. latency didnt seem to change sadly.. still having bad latency wish some1 can help me fix this latency ^^
|
many thx
User was warned for this post.
|
Link doesn't work anymore.
|
On May 30 2020 22:55 SC-Shield wrote:Link doesn't work anymore. No shit sherlock.. The thread is 10 years old!! Why is it even possible to bump super-old topics? They should be closed automatically after a year or so.
|
On May 31 2020 07:15 [N3O]r3d33m3r wrote:No shit sherlock.. The thread is 10 years old!! Why is it even possible to bump super-old topics? They should be closed automatically after a year or so.
I didn't see that link was 10 years old, someone bumped the thread. No need to be sarcastic.
|
|
|
|