logsecrets collision setting

[ninjaMooCow]

Possibly in pauling/server/server.go

So I manage a large pool of servers by adding a logaddress and a logsecret, much like I think what you are doing here. Then I receive UDP into a custom client that is able to demux the UDP log packets by logsecret. I can then update my db so that my "system" knows which servers are doing what, and I collect log files, etc.

This worked fine up until a recent change when this happens a lot:

(from tf2 server log)
S8906144840569881299L 04/05/2016 - 20:33:51: rcon from "192.223.31.240:48901": command "sv_logsecret 8906144840569881299; logaddress_add 192.223.31.240:3003"
S8906144840569881299L 04/05/2016 - 20:34:01: rcon from "192.223.31.240:48901": command "sv_logsecret 8906144840569881299; logaddress_add 192.223.31.240:3003"

One may argue that doing this every 10s is excessive. But in any case, what happens is that by changing my purposely set logsecret, my "system" is no unable to demux the UDP and tell which server which log file is for.

The logaddress_add is friendly in allowing multiple IPs, so that isn't a big issue. It still leaves my address in there to get UDP packets.

The single IP / demux is not a new pattern. It is used by hlstatsx, I believe. I copied the pattern (and wrote my own code.)

I think your change was probably to avoid having to identify your server based on having a bunch of ports open and each server log gets its own port.

I know that this has broken my system. I suspect it may also break serveme, although I didn't ask Arie. I know they use logsecret in a similar way to what you have here.

I can retool my system to allow for listening on multiple ports (I only have 10 servers, after all.) But I wanted to raise an issue so that you knew your design change choices have had an unforseen impact.

ty.

[Arie]

TF2Stadium sets their own logsecret for serveme.tf reservations made through the API, so it's not an issue for those.

It would be wise to reuse a logsecret if there is one, and set a new one if there isn't one though.