-
Notifications
You must be signed in to change notification settings - Fork 521
Changing default Protocol from TCP to WebSockets. #1420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…enance on 2024/08/27 some servers in affected regions will no longer accept TCP connections, which can prevent clients from ever making a successful connection in some cases. WebSockets appear to be the preferred protocol, so that should now be the new default.
|
That also suggests a secondary bug in the server selection logic, if we can't connect to one server we should be trying again on another. |
SteamKit2/SteamKit2/Steam/SteamClient/Configuration/SteamConfigurationBuilder.cs
Outdated
Show resolved
Hide resolved
…gurationBuilder.cs Co-authored-by: Antoine Rybacki <[email protected]>
The retry logic is definitely working as intended, I can see that the servers are being iterated over as they fail. Part of the issue here might be due to Taking a look at the logs from my Steam client it doesn't seem like the TCP servers are even considered, it just goes ahead and picks WebSockets : Is Valve trying to decommission their TCP servers and move over to WebSockets exclusively? It would make sense that after server maintenance that some servers might no longer be accepting new TCP connections. |
|
I thought the default was All instead of force TCP. |
|
SteamClient has defaulted to TCP as far back as I remember and as far back as I can find code for, but I thought we changed that more recently. I suppose not. And yes, I do believe that the long term plan is to migrate all of Steam over to WebSockets and dump the TCP and UDP implementations. |
After Valve's maintenance on 2024/08/27 some servers in affected regions will no longer accept TCP connections, which can prevent clients from ever making a successful connection in some cases.
For example CellId 63 (Washington DC) will endlessly retry the same servers without ever making a successful connection. I have tested and confirmed that other regions are affected by this issue, however I don't remember which ones off the top of my head.
