wir haben eine firewall-rule gebaut, die die requests an den content server auf unseren eigenen content server umleiten. das hat das problem allerdings nicht behoben - statt dessen macht der content server selber jetzt einen syn_sent an einen anderen content server.
grundsätzlich scheint es 2 probleme zu geben:
1. der masterserver antwortet nicht oder sehr spät
2. der content server antwortet nicht
zu 1)
wir haben per firewall rule die requests umgeleitet, bringt aber nix. es scheint was zu bringen, wenn man die ClientRegistry.blob löscht, zumindest steigen die Erfolgschancen
zu 2)
die ursache liegt m.E. darin, dass der client einen request an einen content server stellt, der eigentlich den status "filtered" hat. gefilterte content server geben nur updates an clients frei, die für diesen content server freigegeben sind (das wird per firewall regel definiert). nur leider scheint das dem masterserver wurscht zu sein: er leitet content update requests von clients eben auch an content server weiter, die nicht public sind. und dann kann man eben auf das update warten, bis irgendwann der timeout überschritten ist. ich habe in 2007 mehrmals mit mike dunkle von valve darüber gesprochen, sein fazit war, dass es für valve keinen sinn machen würde, viel energie in die behebung des problems zu stecken. in der valve mailingliste haben auch schon einige poster auf das problem hingewiesen, aber bei valve hält man sich sytematisch zurück, wenn es um dieses thema geht.
