Если сервер игры упал, встреча всё равно состоится?

Сценка: вымышленная история.

Нас шестеро, кооператив раз в неделю — святое. Я подняла игровой сервер на VPS: накатила образ, прописала автозапуск, потыкала настройки. Работает.

А теперь представила: вечер, все в сети, сервер молчит. Мой план Б — настолки под кроватью и чайник. Слабовато.

Какой у вас запасной ход: локалка у кого-то дома, другая игра, голосовой чат и печеньки?

У нас летом такое: упал wi-fi, и все номера одновременно вспоминают, что им срочно нужен интернет. Спасает не техника, а договорённость — чай на террасе и честное «вернётся через час». Так что голосовой чат и печеньки — нормальная встреча. Главное заранее решить, кто объявляет переход на запасной вариант, а то половина будет сидеть у мёртвого сервера, пока вторая уже ест печеньки без них.

Про «кто объявляет»: я бы убрал это из человеческих рук. n8n пингует сервер, молчит пять минут — бот сам кидает в чат «план Б, печеньки». Сценарий быстрее шестерых спорящих.

leo_msk писал:
бот сам кидает в чат «план Б, печеньки»

Красиво, пока бот не объявит план Б из-за того, что я сама перезагрузила сервер патчем за десять минут до старта. У нас ведь так и будет: пять минут молчания — это не авария, это я опять что-то докручиваю.

Хотя идея с автоматом нравится. Пусть пингует, но не пять минут, а пятнадцать — мой стандартный срок «ой, щас, ещё разок». Тогда к его авторитету хотя бы можно будет относиться всерьёз.

Мира, тут классика: не учить бота отличать аварию от патча — он всё равно ошибётся, — а дать тебе кнопку «это я».

Перед перезагрузкой шлёпаешь боту /patch — вотчдог молчит двадцать минут. А если забыла нажать, пусть работает в два этапа: пятнадцать минут тишины → он пишет тебе в личку «ты чинишь?», три минуты нет ответа → только тогда объявляет всем план Б. Так твоё «ой, щас, ещё разок» не срывает встречу, но и настоящая тишина мимо не пройдёт.

И про проверку: пинг — слабый признак. VPS отвечает на icmp, а игровой процесс при этом уже лёг. Дёргай сам порт игры или query-протокол, если он у игры есть. Минимальный пример для TCP:

import socket

def alive(host: str, port: int) -> bool:
    try:
        with socket.create_connection((host, port), timeout=3):
            return True
    except OSError:
        return False

Если игра на UDP — кидаешь туда пакет и ждёшь ответ, чуть геморнее, но принцип тот же: проверяем игру, а не машину.

Я однажды настроил вотчдог, который следил за моим же ботом. Вечером перезапускал его руками и забыл — он три раза за вечер радостно сообщил чату «всё упало» )) С тех пор кнопку «я сам» дописываю первой.

tema_py писал:
вотчдог молчит двадцать минут

Молчать он должен только по твоей команде. Иначе встречу отменит любой шутник из чата — без взлома, одной строкой.

n1kita писал:
Молчать он должен только по твоей команде. Иначе встречу отменит любой шутник из чата — без взлома, одной строкой.

Справедливо, проглядел. Команда есть, а «чья она» — не проверял. Правится фильтром по user id:

ADMINS = {123456789}  # id Миры, подставить свой

async def patch(update, context):
    if update.effective_user.id not in ADMINS:
        await update.message.reply_text("кнопка не твоя, шутник")
        return
    # глушим вотчдог на 20 минут

Два момента. Проверять именно id, не username — ник меняется за минуту, id нет. И чужие /patch молча игнорить не стоит: человек не поймёт, сработало или нет. Ответил — и пошёл дальше.

А когда кнопку нажала Мира — пусть бот сам пишет в чат «Мира чинит, тишина двадцать минут». Никакого тайного выключателя: все видят, кто ткнул и когда.

Честно признаю: в своём вотчдоге про шутника не подумал ровно потому, что шутником там обычно был я))

А у меня запасной ход технически без ботов. На роутере включен запасной маршрут через мобильный интернет, если основной провайдер отваливается. Роутер сам переключает, сервер продолжает работать. Если уж и там всё легло — тогда да, печеньки.

pavel_63 писал:
Роутер сам переключает, сервер продолжает работать

Мечта. У нас бы всё равно кто-то по привычке нажал «переподключиться» десять раз и спрашивал, почему не заходит.

mira_games писал:
Пусть пингует, но не пять минут, а пятнадцать — мой стандартный срок «ой, щас, ещё разок».

Принято, пятнадцать. Порог вообще не должен придумывать я — он измеряется по хозяйке сервера. У меня дома ollama после рестарта прогревается минуты две, и я как-то поставил трёхминутный порог на свой же пайплайн: он сообщал «всё упало» при каждом обновлении модели. Так что «пять минут» была моя ошибка, а не число.

С кнопкой /patch от tema_py сценарий в n8n теперь выглядит так, текстом:

— раз в минуту TCP-коннект на порт игры, не icmp: промах — счётчик +1 в переменной, успех — сброс;
— 15 промахов подряд — личка «ты чинишь?»;
— 3 минуты тишины — в чат «план Б, печеньки»;
— /patch с твоего id — mute на 20 минут, и бот сам пишет, кто нажал.

И хвост, про который все забыли: обратное объявление. Сервер поднялся, счётчик сбросился — бот обязан сам кинуть «жив, возвращаемся». Иначе половина будет жевать печеньки, пока сервер уже работает, — ровно та раздвоённость, с которой начинали.

leo_msk писал:
бот обязан сам кинуть «жив, возвращаемся»

И пусть заодно удаляет своё «план Б» или редактирует на «отбой». У меня в чате старое объявление живёт дольше самой аварии: через час кто-то отвечает на него «а чё случилось» — и половина снова сидит жуёт печеньки ))

Закреп «бот отвалился, пишите мне» однажды провисел неделю после того, как я его починил. Никто не листает вверх, все читают последнее.

hopstop писал:
старое объявление живёт дольше самой аварии

Чтобы «отбой» из схемы Лёвы реально случился, бот должен помнить, какое сообщение редактировать.

Кинул «план Б» — сохрани message_id туда же, где живёт счётчик промахов, только не в переменную, а в файл или sqlite. Между «упало» и «поднялось» ты этого бота ещё раз пять перезапустишь руками (я бы точно перезапустил), айдишник в памяти умрёт — и объявление останется висеть зомби.

msg = await context.bot.send_message(chat_id, "план Б, печеньки")
state["plan_b"] = msg.message_id  # state живёт на диске

# сервер поднялся, счётчик сброшен:
await context.bot.edit_message_text(
    chat_id=chat_id,
    message_id=state["plan_b"],
    text="отбой, сервер жив, возвращаемся",
)

Редактировать, а не удалять: после удаления всё равно прибегут спрашивать «а чё было», а тут вся драма в одном сообщении — упало, отбой, плюс пометка «изменено», так что никто не решит, что бот газлайтит чат. И если «план Б» закреплял — не забудь unpin_chat_message, закреп сам не слезет.

Я раньше такие объявления редактировал руками со своего аккаунта. Очень надёжная технология, если не считать того, что руки в этот момент уже держали печеньку ))

Артём, с сохранением сообщения согласна. Только мне не нравится автоматическое «возвращаемся». Представим, мы уже начали настолку, а сервер ожил. Теперь бот зовёт всех обратно, и встреча снова рвётся пополам. Он ведь не знает, хотим ли мы ещё переключаться.

Пусть сообщает только факт: сервер снова отвечает. А возвращает людей ведущий встречи. Это две разные кнопки. Иначе автомат очень старательно организует вам вечер, в котором никто не успевает ни поиграть, ни доесть печеньки)

Да, «отбой» у меня слишком командирский получился)) Я бы менял текст на «сервер доступен, решение о возвращении за Мирой». Старое объявление перестаёт пугать, но бот не вырывает у людей карты из рук.

Принимаю разделение. Из автомата оставляем проверку состояния, уведомление и редактирование старого сообщения. «Меняем занятие» убираем. Я начал с удобного переключателя и незаметно поручил ему решать, чем людям сегодня заниматься.

Вот этот вариант мне подходит: бот сообщает, я решаю, группа заранее знает запасной ход. Если уже разложили игру, доигрываем. Наш маленький сервер может вернуться к жизни без торжественного возвращения шестерых человек к мониторам)

начинали с запасного сервера, закончили правом спокойно доесть печеньку. по-моему, это редкий тред, где техническое решение стало проще по мере обсуждения)

С сервером и объявлениями разобрались. А если я опоздаю к началу? Всё работает, люди собрались, но по привычке ждут меня. Не хочется чинить встречу после каждого моего опоздания) Нужен второй ведущий, который может начать без меня, а не ещё один человек, которому дали пароль от сервера.

Я бы назначил второго заранее и разделил права. Вести встречу — одно, перезапускать сервер и глушить уведомления — другое. Запасному ведущему не обязательно уметь всё. Зато остальные должны знать, кто сейчас собирает группу и решает, начинаем или ждём.

И пусть второй подтвердит, что принял роль. Назначить отсутствующего человека — легко, дождаться его «да, начну без тебя» полезнее) А когда Мира придёт, не надо автоматически передавать вечер обратно. Уже начатую встречу можно спокойно довести с тем, кто её начал.

Для запасного ведущего ещё важно видеть, в каком состоянии встреча: собираемся, играем, закончили. Доступный сервер этого не рассказывает. После завершения уже нечего «возвращать», даже если машина починилась только ночью.

Добавляю завершение встречи в тот же короткий набор действий ведущего. Передать роль можно, вернуть вечер назад нельзя) После закрытия бот уже не зовёт людей к ожившему серверу, а следующая встреча начинается отдельным событием.

И позднему участнику хватит одной итоговой строки: «Сегодня закончили, следующая встреча тогда-то». Не заставлять его читать историю передачи роли и перезапусков. Пусть в закрепе будет то, что человеку делать сейчас, а не вся служебная переписка.

Раз следующая встреча начинается отдельным событием, её объявлению тоже нужен свой номер или дата. После перезапуска бот может помнить старый message_id. Не хочу, чтобы новое «сервер доступен» вдруг отредактировало итог прошлого четверга)

Тогда сохраняем не просто «последнее сообщение про поломку», а к какой встрече оно относится. Закрытая встреча не открывается снова от нового ответа сервера. И имя поля plan_b наконец перестанет быть вечным мешком для всех наших четвергов)

Да, событие проверки должно знать, к какому объявлению относится. Если работа перезапустилась, сначала сверяем текущую встречу и её состояние, потом редактируем сообщение. Один сохранённый message_id решает потерю памяти, но не путаницу разных вечеров.