Steam & WA Freezone

HavocXphere

New member
As some of you may be aware, Valve introduced a new HTTP based content delivery system some time ago.

A side effect of that is that all the methods previously used (Firewall configs, Frey's, Steamwatch etc) are now useless. Because both the store and content now run over port 80, simple filtering by port is now a fundamentally flawed approach.

The only thing that works correctly right now is Steam-limiter. Its vastly more sophisticated than the above mentioned approaches since the underlying mechanism used is different (dll injection to rewrite IPs on the fly :eek:), so big props to the dev (Nigel Bree).

HX
 
As far as I know it's only for certain titles and hasn't been completely rolled out but I might be wrong.
 
Fuck. That's why my speeds on some of my downloads have been so sucky on Steam lately. Openweb shapes my http downloads into oblivion. :/
 
I recently downloaded Alan Wake at 1MB/s (10Mb line) :D Usually on Steam I struggled to get such high downloads (unless it was hosted locally on WA Freezone), but recently its cruising at breakneck speeds.

What sucks though, is that its now using my normal cap :(

Not sure what to think of this change. Guess I have to schedule my Steam downloads after 12am from now on.
 
Last edited:
As far as I know it's only for certain titles and hasn't been completely rolled out but I might be wrong.
Yes some titles only. Pretty much everything going forward will be on the new system though. Noticed it yesterday for the first time when a Rome TW download breezed past my firewall filters.

Not sure what to think of this change.
When taking the net-limiter prog into account its actually a big improvement above the previous setups. Because the IPs get rewritten, Steam is much more enthusiastic about actually using the WA servers. Also, finally saw some delta-patching actually happen, which will save ZA gamers much pain.
 
so big props to the dev
You're welcome. Not many people give feedback (which is perfectly fine too, of course), but it's certainly nice to get it. :-)

Apropros of which, to learn about new ISPs I do need to rely on people telling me about what filter rules to apply for them, and/or to give me a heads-up if there are performance reasons to tweak the rules.

The performance thing is particularly reliant on folks suggesting things; I know that in Australia, lots of people still get benefit from using a tool to shape the Steam traffic even if it's not completely unmetered, just because Steam really doesn't do a great job of choosing servers that are on the same continent (and so which have low latency).

Quite probably the same thing also applies in South Africa for ISPs that don't run their own Steam servers, but folks would have to test that out and play with alternatives to figure out whether it makes a difference or not (if so, it's easy for me to add those ISPs to the supported table with suitable rules that point at a suitable set of local servers). So if maybe someone on Openweb can try using the webafrica limiter rule, I can know whether it's a good idea to recognize Openweb and serve that rule up for it.

What sucks though, is that its now using my normal cap :(
Yeah; the deal with the HTTP downloads in particular is that Valve's systems are aware of what is hosted on every content server, so if a piece of content is relatively new (like Alan Wake) then it won't have been replicated everywhere yet. When that's the case and you go to download, Valve's master servers will point your Steam client at a list of places to download from that it knows do have the content, and those could basically be anywhere because from Valve's point of view having the download "just work" is all that matters.

If you're using a Steam filter that's HTTP-aware then in that case, the download would tend to stall or fail instead; which is annoying, but it at least puts you in the driver's seat and you can make informed choices about whether to (or when to) disable the filter just for that one title.

Yes some titles only. Pretty much everything going forward will be on the new system though.
Pretty much this. The thing with making a big change like this is that it affects the individual game publishers too; Valve will have had a manual with a set of processes for publishers to go through to prepare content for the old port 27030 CDN and even more important than the code for the new HTTP-based one is that they'll now have a different set of processes to prepare (including test, remember) content for the new one. So, making the changeover takes a time and energy investment from everyone involved; Valve won't want to maintain both sets of publishing processes for new content in parallel for longer than they have to, but migrating stuff from the old CDN to the new one will also cost Valve money so you can expect both to stay in place for a fair while yet.
 
Back
Top