By the way, I'll just toss in the side observation that since this is standard HTTP content delivered over regular HTTP, if anyone with any networking knowledge had spent 30 seconds looking at the question then it would be obvious that all that's necessary to efficiently offer Steam downloads over HTTP unmetered to customers is a bog standard HTTP cache like Squid. Of course, to make that work you still need something like steam-limiter to force the DNS issue so that the Steam client supplies the appropriate host: header, but then your customers absolutely have to be running something like that anyway.

[ I'll also observe that the only thing that varies in these kind of download systems is the manifests - the actual file chunks in these systems tend to be immutable because that's what make the underlying push-replication systems work efficiently behind the scenes, as in the likes of Akamai. Using a Squid cache instead of Valve's normal replication can't get the benefits of an Akamai-like private non-Internet replication network (although since Valve apparently aren't using Akamai and TC seem to have an active policy of not peering with anyone, I rather doubt you get that anyway), but given that the file chunks are immutable the retention policy of the Squid cache can be set so that it would seem to be exactly the same from a cost standpoint to TC as having an official server. ]

And this is true for any ISP in NZ, of course. That would be an unutterably cheap and nasty way of doing it, and it's still pretty customer-hostile compared to the good market equilibrium when we have ISPs freely peering locally hosted content like this. But it would work, and any NZ ISP could do it in a trice of they cared. The fact that none of them have bothered speaks volumes as to how important this is to ISPs.

Is this going to be upgraded at any time telstra?

Probably not, because this is a classic kind of coordination problem between the NZ ISPs.

In other markets (South Africa and Australia) where local Steam servers are popular, the majority of market players have steam servers which are unfiltered, and thus can and do serve HTTP content for the new CDN while having unmetering arrangements for their own customers  - and since almost all the ISPs in those markets run unfiltered, there's no reason why any new server anyone stands up in that market needs to be filtered either. That's the good market equilibrium.

Now, we don't know "officially" why Valve have probably decided to require unfiltered servers, but if you look at how things work technically we can observe that in their HTTP CDN, the server selection is done almost completely by DNS lookup - including filtered servers in the result sets from their DNS servers could cause serious problems for Valve's customers if they return a filtered server to someone who isn't going to be able to access it.

[ There is a separate mechanism in their HTTP CDN that could allow filtered servers to be used rotation, but it's going to be tedious for Valve to use it for this and Valve probably have no real interest in spending more of their money and staff time on something as spectacularly unnecessary as allowing ISPs to play these kind of childish games. ]

Here in NZ part of the use of filtered servers is (like the generally anti-customer approach taken by local ISPs to peering arrangements) a way of ensuring that the very limited resources that ISPs want to devote to hosting a server are delivered only to their customers, without yielding any benefit the customers of other ISPs. That's a counterproductive thing to worry about, and of course once unfiltered servers start appearing (i.e. someone takes on the externality of supplying other ISPs customers) then the natural game-theoretic equilibrium is for everyone to run unfiltered servers, at which point the externality becomes pretty much a non-issue. But in the meantime, because of that externality, the first servers to appear were filtered and thus we've ended up with that as a market equilibrium.

The fact we face is that the NZ ISPs have all independently voted for a beggar-thy-neighbour market equilibrium where everyone runs filtered servers so everyone's customers suffer. Unfortunately that's a stable equilibrium, so unless a provider brave enough to break the current dysfunctional market state comes along we're probably all out of luck no matter what ISP we're with.

I don't believe the reason for your problem was Steam using HTTP; TcpView was showing that the connection is being made on port 27030, which is the classic steam content server protocol, whereas HTTP connections would show either as plain http (for port 80) in TcpView, or as connections to localhost on some other port depending on any personal firewall software being used (some of which redirects all HTTP traffic to a special proxy process to check it for safety).

However, I'm glad to hear the limiter application does the trick for you; "little" and "just works" were my primary goals in making it.

Note that I currently block HTTP downloads from the main Steam servers, but that's a stopgap while the TC steam server doesn't have port 80 open. I'll have to revise the app when that happens and I can observe the Steam client's actual behaviour in action. Until then I can't tell just what kind of encouragement it will *really* need to avoid using different http servers. It may be that the best approach once the TC server is available is to return a fake DNS result for the main Steam servers that points at the TC server, but until that server is really up it's better to pretend to the Steam client that the main http servers don't exist.

Last week when TelstraClear sent out the e-mail announce for this, since I have a gaming machine still running XP I quickly threw together a tool for my own use to limit Steam's content server connections. It's available at http://code.google.com/p/steam-limiter/ - like the other tools mentioned above it won't attempt to filter http downloads, but for anything on port 27030 it will limit Steam's connections to a specific server with no leakage by hooking into Windows Sockets so it can do the port-specific filtering and redirect connections to other servers to the unmetered one.

Given that it's at least in the "Works on My Machine" state (or two machines, on XP and one running Win7 32-bit) it's at least there if anyone wants to give it a try.