Thanks for your help. Post a reply here if you have any issues. We’re especially interested in hearing your results if you are running an older distribution of linux or have a complicated network environment. (Multi-homed, NAT, etc.)

This change will also be coming to the older Source games, as well. The binaries in this zip *should* be compatible with those games, although I haven’t tested it specifically so there might be an issue. We’ll send a similar announcement
to operators of those servers on the appropriate mailing list when we get closer to updating those games.

- Fletch

README.TXT:

Thanks for helping test compatibility with these new Steam binaries for the

dedicated server.

Place the files for your platform into your "bin" folder. They should replace

files with the same name. (steamerrorreporter.exe on Win32 is new.)

**PLEASE DELETE** the files listed below, if they are present:

Linux:

libstdc++.so.6

libtier0_s.so

libvstdlib_s.so

libsteam.so

Windows:

steam.dll

We believe that they are no longer be needed and we will no longer be shipping them.

Please let us know if this is not the case.

These binaries will communicate with Steam using the new WebSockets protocol. Previously

a bespoke UDP protocol was used. You should see a TCP connection to a Valve server on

port 443, bound to a local ephemeral port. There is currently no mechanism to control

what local IP or port this connection is bound to. However, it does obey HTTP proxy,

so if you need to control the public IP you can do that. (The master server may refuse

to list your server if the public IP used to talk to Steam does not match the IP you are

advertising for game traffic.) Alternatively, you can add "-udpforce" on the command line

to disable websockets and force the use of the old UDP protocol. Please don't do this

unless you need to. In the future WebSockets will be the preferred (and better-supported)

protocol. The UDP protocol will likely be around for some time, but eventually we'll

phase it out.

Things to test:

* Does the server boot with those files deleted. (Especially on old distros.)

* Does the server have any trouble talking to Steam using websockets.

The connection_log[_xxx].txt file is also a potentially interesting source of

information about how your server is talking to Steam.

We will make a special announcement when we release the update that makes this change.

Until you see that announcement, you can assume that no change has been made to the

Thanks for your help. Post a reply here if you have any issues. We’re especially interested in hearing your results if you are running an older distribution of linux or have a complicated network environment. (Multi-homed, NAT, etc.)

This change will also be coming to the older Source games, as well. The binaries in this zip *should* be compatible with those games, although I haven’t tested it specifically so there might be an issue. We’ll send a similar announcement
to operators of those servers on the appropriate mailing list when we get closer to updating those games.

- Fletch

README.TXT:

Thanks for helping test compatibility with these new Steam binaries for the

dedicated server.

Place the files for your platform into your "bin" folder. They should replace

files with the same name. (steamerrorreporter.exe on Win32 is new.)

**PLEASE DELETE** the files listed below, if they are present:

Linux:

libstdc++.so.6

libtier0_s.so

libvstdlib_s.so

libsteam.so

Windows:

steam.dll

We believe that they are no longer be needed and we will no longer be shipping them.

Please let us know if this is not the case.

These binaries will communicate with Steam using the new WebSockets protocol. Previously

a bespoke UDP protocol was used. You should see a TCP connection to a Valve server on

port 443, bound to a local ephemeral port. There is currently no mechanism to control

what local IP or port this connection is bound to. However, it does obey HTTP proxy,

so if you need to control the public IP you can do that. (The master server may refuse

to list your server if the public IP used to talk to Steam does not match the IP you are

advertising for game traffic.) Alternatively, you can add "-udpforce" on the command line

to disable websockets and force the use of the old UDP protocol. Please don't do this

unless you need to. In the future WebSockets will be the preferred (and better-supported)

protocol. The UDP protocol will likely be around for some time, but eventually we'll

phase it out.

Things to test:

* Does the server boot with those files deleted. (Especially on old distros.)

* Does the server have any trouble talking to Steam using websockets.

The connection_log[_xxx].txt file is also a potentially interesting source of

information about how your server is talking to Steam.

We will make a special announcement when we release the update that makes this change.

Until you see that announcement, you can assume that no change has been made to the

Thanks for your help. Post a reply here if you have any issues. We’re especially interested in hearing your results if you are running an older distribution of linux or have a complicated network environment. (Multi-homed, NAT, etc.)

This change will also be coming to the older Source games, as well. The binaries in this zip *should* be compatible with those games, although I haven’t tested it specifically so there might be an issue. We’ll send a similar announcement
to operators of those servers on the appropriate mailing list when we get closer to updating those games.

- Fletch

README.TXT:

Thanks for helping test compatibility with these new Steam binaries for the

dedicated server.

Place the files for your platform into your "bin" folder. They should replace

files with the same name. (steamerrorreporter.exe on Win32 is new.)

**PLEASE DELETE** the files listed below, if they are present:

Linux:

libstdc++.so.6

libtier0_s.so

libvstdlib_s.so

libsteam.so

Windows:

steam.dll

We believe that they are no longer be needed and we will no longer be shipping them.

Please let us know if this is not the case.

These binaries will communicate with Steam using the new WebSockets protocol. Previously

a bespoke UDP protocol was used. You should see a TCP connection to a Valve server on

port 443, bound to a local ephemeral port. There is currently no mechanism to control

what local IP or port this connection is bound to. However, it does obey HTTP proxy,

so if you need to control the public IP you can do that. (The master server may refuse

to list your server if the public IP used to talk to Steam does not match the IP you are

advertising for game traffic.) Alternatively, you can add "-udpforce" on the command line

to disable websockets and force the use of the old UDP protocol. Please don't do this

unless you need to. In the future WebSockets will be the preferred (and better-supported)

protocol. The UDP protocol will likely be around for some time, but eventually we'll

phase it out.

Things to test:

* Does the server boot with those files deleted. (Especially on old distros.)

* Does the server have any trouble talking to Steam using websockets.

The connection_log[_xxx].txt file is also a potentially interesting source of

information about how your server is talking to Steam.

We will make a special announcement when we release the update that makes this change.

Until you see that announcement, you can assume that no change has been made to the

Thanks for your help. Post a reply here if you have any issues. We’re especially interested in hearing your results if you are running an older distribution of linux or have a complicated network environment. (Multi-homed, NAT, etc.)

This change will also be coming to the older Source games, as well. The binaries in this zip *should* be compatible with those games, although I haven’t tested it specifically so there might be an issue. We’ll send a similar announcement
to operators of those servers on the appropriate mailing list when we get closer to updating those games.

- Fletch

README.TXT:

Thanks for helping test compatibility with these new Steam binaries for the

dedicated server.

Place the files for your platform into your "bin" folder. They should replace

files with the same name. (steamerrorreporter.exe on Win32 is new.)

**PLEASE DELETE** the files listed below, if they are present:

Linux:

libstdc++.so.6

libtier0_s.so

libvstdlib_s.so

libsteam.so

Windows:

steam.dll

We believe that they are no longer be needed and we will no longer be shipping them.

Please let us know if this is not the case.

These binaries will communicate with Steam using the new WebSockets protocol. Previously

a bespoke UDP protocol was used. You should see a TCP connection to a Valve server on

port 443, bound to a local ephemeral port. There is currently no mechanism to control

what local IP or port this connection is bound to. However, it does obey HTTP proxy,

so if you need to control the public IP you can do that. (The master server may refuse

to list your server if the public IP used to talk to Steam does not match the IP you are

advertising for game traffic.) Alternatively, you can add "-udpforce" on the command line

to disable websockets and force the use of the old UDP protocol. Please don't do this

unless you need to. In the future WebSockets will be the preferred (and better-supported)

protocol. The UDP protocol will likely be around for some time, but eventually we'll

phase it out.

Things to test:

* Does the server boot with those files deleted. (Especially on old distros.)

* Does the server have any trouble talking to Steam using websockets.

The connection_log[_xxx].txt file is also a potentially interesting source of

information about how your server is talking to Steam.

We will make a special announcement when we release the update that makes this change.

Until you see that announcement, you can assume that no change has been made to the

Re: Compatibility test for incoming change

what local IP or port this connection is
bound to. ... (The master server may refuse

to list your server if the public IP used to
talk to Steam does not match the IP you are

advertising for game traffic.)

This would make the new mechanism incompatible with our systems,
because all machines here have multiple IP addresses. Some other
games have this same design flaw, including some Valve games on
Linux (at least, historically). As Kyle does, we have a firewall
rule in place on Linux that drops TCP connections to 27017:27019 on
the outbound as a workaround for this (forcing a fallback to UDP
mode).

Before the official release, or at least before you phase out
-udpforce, you should modify the software to do a bind() call before
connect(), using the IP address specified on the command line.

Re: Compatibility test for incoming change

I don’t know if/when we’ll have a better solution than HTTP proxy for controlling the public IP for websockets. However, in the meantime, -udpforce on the command
line should work. Can you please confirm that it does?

I’m sure we’ll make sure there is a reasonable solution for multihomed servers.

what local IP or port this connection is bound to. ... (The master server may refuse

to list your server if the public IP used to talk to Steam does not match the IP you are

advertising for game traffic.)

This would make the new mechanism incompatible with our systems, because all machines here have multiple IP addresses. Some other games have this same design flaw, including some Valve games on Linux (at least, historically). As Kyle does, we have a firewall
rule in place on Linux that drops TCP connections to 27017:27019 on the outbound as a workaround for this (forcing a fallback to UDP mode).

Before the official release, or at least before you phase out -udpforce, you should modify the software to do a bind() call before connect(), using the IP address specified on the command line.