Signal handling: switch servers, reload config, etc.

[ropery]

A useful but missing feature: when the currently connected server is slow, the user should be able to tell sslocal to switch to another server immediately.

We can take a leaf out of tor's signal handling book:

SIGHUP
    The signal instructs Tor to reload its configuration (including closing and
    reopening logs), and kill and restart its helper processes if applicable.

SIGUSR1
    Log statistics about current connections, past connections, and throughput.

SIGUSR2
    Switch all logs to loglevel debug. You can go back to the old loglevels by
    sending a SIGHUP.

Analogously, sslocal would remember the config passed via -c, and reload it upon receiving SIGHUP. We can use SIGUSR1 for "switch servers now" (perhaps lowering the "score" of the previous server, too, basically marking it as kind of slow right now... if sslocal keeps such a "score" on servers, that is. And if so, SIGHUP should also reset all server scores.)

What do you think?

[zonyitoo]

If you set the score manually, should sslocal keep testing that server after that?

• If so, then that server will "come back" after some tests, because it is still one of the "best" of the servers
• If not, then why not just delete it from configuration?

Maybe it would be better to optimize the server probing algorithm.

[ropery]

Controlling via signals is limited (only 3? signals) and not as expressive (no "content" within the signal) as say RPC, but is I'd think simpler to implement. And because of the limited nature of this interface, we should indeed choose carefully the what & how of it.

Maybe it would be better to optimize the server probing algorithm.

True, if sslocal become smart enough to always rank the servers per actual performance or "user experience", everything would just work and the user would just forget about it.

However, as things stand now, when connected to a slow server, we're stuck with it for a (potentially long) while, with no way to tell sslocal to switch to another server short of killing & restarting sslocal. A live controlling interface would be a welcome addition with or without a smarter server-ranking algorithm.

If so, then that server will "come back" after some tests

Good point. Without knowledge of the server-scoring algorithm, I can think of a few options:

1. The most crude & simple: when the user sends the signal to switch from server X, X is blacklisted.
2. Three-strike: similar to the above, but X is blacklisted only after three such switches.
3. Weighted, graded: each time we manually switch from server X, its "weight" is reduced, so that sslocal will either be less likely to choose it among the good servers, or wait longer before using it again, (i.e., "probabilistic" vs scheduling, with similar results.)

Basically, it's about incorporating user feedback into the server-ranking or -scoring algorithm. The algorithm is unlikely to ever be perfect, so this type of user assistance will remain helpful.

If not, then why not just delete it from configuration?

Some servers work well now and poorly then, so you want to disable them only temporarily.

[zonyitoo]

The current ranking algorithm is to probe round-trip-time for each server with the same address.

Each server will keep 99 of recent results, and calculates their median and standard deviation, calcuate score as:

https://github.com/shadowsocks/shadowsocks-rust/blob/b501ec6fd5cea3e7cddb70719ddf78a31f6817fe/src/relay/loadbalancing/server.rs#L79-L100

So if your server became slow occasionally, standard deviation should become higher than other servers.