Настройка передачи с высокой пропускной способностью
Начиная с Robust Toolbox версии 271.1.0 движок поддерживает режим передачи «с высокой пропускной способностью», использующий WebSockets. Это позволяет таким функциям, как загрузка/скачивание административных ресурсов, иметь более высокую пропускную способность, чем поддерживает обычный сетевой слой игры, но требует дополнительной настройки сервера. Контент может реализовать дополнительные функции через интерфейс ITransferManager.
В отличие от обычного игрового трафика, Robust не реализует слой шифрования для данных WebSocket. Поэтому рекомендуется размещать HTTP API статуса игры за обратным прокси, обеспечивающим TLS, иначе трафик будет незащищённым. Мы будем считать, что вы знаете, как настроить свой веб-сервер с SSL, или, по крайней мере, знаете, как справиться самостоятельно, если не хотите шифровать данные.
Конфигурация игрового сервера
Основные CVars находятся здесь (Учтите, что это permalink, к моменту написания этой страницы могло появиться больше CVars).
Главная переменная, о которой стоит беспокоиться, — transfer.http_endpoint; она должна указывать на HTTP API сервера (ту самую штуку с /status и /info, если вы когда-нибудь её запрашивали). В большинстве случаев это будет то же значение, что и hub.server_url, только с заменой ss14:// на http:// и ss14s:// на https://, и с добавлением номера порта (по умолчанию :1212).
Вы можете задать их прямо на работающем сервере, изменив CVars командой sudo cvar.
Учтите, что только игроки, подключающиеся после включения системы http-передачи, будут действительно использовать систему высокой пропускной способности, а уже подключённые игроки останутся на резервном lidgren, пока не переподключатся.
Очевидно, чтобы изменения сохранились, вам также нужно задать их в своём конфиге.
Пример из Wizard’s Den Vulture:
[transfer]
http = true
http_endpoint = "https://leviathan.spacestation14.com/vulture"
Если вы не хотите использовать шифрование или хотите использовать IP вместо адреса, ваш конфиг может выглядеть так:
[transfer]
http = true
http_endpoint = "http://203.0.113.125:1212"
Если вы не используете обратный прокси… это должно просто заработать! Попробуйте (пере)подключиться и посмотрите, удаётся ли вам успешно подключиться!
Настройка обратного прокси
Большинство веб-серверов поддерживают перезагрузку конфигурации вместо необходимости полного перезапуска. Вам следует делать это особенно после настройки websockets, так как закрытие соединения отключит всех игроков. А перезапуск веб-сервера приведёт к закрытию всех соединений.
Так что вместо systemctl restart nginx используйте systemctl reload nginx (Или что там у вас настроено для вашего веб-сервера.)
Если вы используете что-то нестандартное, поищите, как перезагрузить его конфигурацию на месте.
Пример Nginx
WebSockets в nginx требуют передачи заголовков Upgrade и Connection; мы следуем примеру конфигурации nginx для WebSockets из их документации.
http {
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
...
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_pass http://localhost:1212/;
}
}
Пример Caddy
Caddy должна автоматически пересылать нужные заголовки при использовании обычной директивы reverse_proxy.
Но будьте осторожны: перезагрузка конфигурации по умолчанию закрывает активные соединения WebSockets (не уверен, почему это поведение по умолчанию), что приведёт к отключению ваших игроков от сервера, поэтому рекомендуем задать stream_timeout и stream_close_delay.
example.com {
reverse_proxy localhost:1215 {
# Да, это технически означает, что если игрок остаётся подключённым к серверу
# 12 часов за одну сессию, его отключат.
# Но, честно говоря... им стоит заняться жизнью и потрогать траву.
stream_timeout 12h
stream_close_delay 12h
}
}