03.23 Ведение совместного проекта

ВНИМАНИЕ - Упражнения для этого занятия не будут работать под WSL, поскольку они требуют захода на машину извне, а виртуальная машина WSL находится за NAT-ом.

Попробуем использовать вот этот сервер (пример работы)

• Подготовка репозиториев: разбиться на пары Author, Committer. Author содержит precious source репозиторий, Committer присылает туда pull-request. Значок « » — непосредственное общение (мимо git).

  Author, Committer

  pip install https://github.com/FrBrGeorge/git-smart-http/releases/download/v0.1.1/git_smart_http-0.1.1-py3-none-any.whl
  git-smart-http &

  Author

  git clone http://localhost:3000/Author
  cd Author

  Committer

  git clone http://localhost:3000/Committer
  cd Committer

  Author

  My repo is at http://<author_ip>:3000/Author

  Committer

  My repo is at http://<committer_ip>:3000/Committer

  git remote add upstream http://<author_ip>:3000/Author

  Author

  git remote add committer http://<committer_ip>:3000/Committer

• Создание и приём pull-реквеста

  Author

  create some commits

  # e. g. cal > calendar
  #       git add .
  #       git commit -m "Initial commit"
  git push

  • Hey, I made a release in branch «branch»!

  Committer

  pull, add commits and push

  git pull upstream «branch»
  # e. g. date >> calendar
  #       git commit -a -m "Add a date"
  git push
  git -P log -1  # get a commit_ID

  • Hey, this is my «commit_ID» pull request!

  Author

  pull, review and push

  git pull committer «commit_ID»
  git push

• Поменяться ролями — теперь у Committer есть свой новый preciuos source репозиторий (назовите его как-нибудь!), а Author присылает туда pull-реквесты (для этого тоже надо создать новый публичный репозиторий). Создать и принять pull-реквест.

• Разминка перед многопользовательским MUD

  • Заставляем работать Тупой netcat и Чат сервер из позапрошлой лекции

  • Заставляем работать пример командной строки, в которую время от времени спамит второй поток вычислений. Может не заработать под виндой или Mac.

  • По аналогии с ним написать более удобный клиент к общему чату:

    • В командной строке должны поддерживаться две команды:

      • hi — шлёт сообщение "Hello everybody" (с помощью .sendall())

      • say сообщение — шлёт сообщение (с помощью .sendall())

    • Приём сообщений делать в отдельном треде (с помощью .recv(1024))

TODO, возможно, хватит времени ещё на что-нибудь!

Д/З

TODO Сделать условие немного более конкретным для удобства автоматической проверки

• Задача_1. Многопользовательский MUD (multiuser multiuser dungeon)

  • Скопируйте решение Задачи_1 с предыдущего занятия. Сделайте коммит. Работайте на ветке work.

  • Сделайте (наконец-то!) MUD многопользовательским. Подробности ниже.
  • Многосессионность (поддержку работы с одним сервером одновременно нескольких клиентов) реализуйте по схеме "коровьего чата" из лекций.
  • Именованные сеансы:

    • При подключении клиента к серверу, клиент передаёт серверу имя пользователя (строка без пробелов, поступает клиенту при запуске - python mymud.py username).

    • Сервер проверяет, что подключенного пользователя с таким именем ещё нет; если есть - отказывает в подключении; если нет, то создает подключение (сообщая об этом клиенту) и запоминает имя пользователя.
  • Асинхронность работы клиента с сервером:
    • после отправки сообщения серверу, клиент НЕ ждёт ответа от сервера

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

    • все сообщения от сервера клиенту предназначены для вывода "as is", никакого разбора в духе "набор параметров от сервера к клиенту" теперь не нужно; т.е. клиент отправляет команды на сервер без ожидания ответа и без "понимания", что сообщения от сервера приходят в ответ на конкретные команды

    • схема параллельного ожидания сообщений и обработки пользовательского ввода - см. лекцию (раздел "Cmd и асинхронные сообщения")

    • важно: после получения от сервера (и вывода) сообщения, клиент должен показать командную строку с набранным (но не введённым) пользователем текстом, чтобы результат ввода не исчезал (опять см. лекцию)
  • Частичная неделимость обработки пользовательской команды на сервере (для ограничения гонок):
    • помним, что сервер последовательный
    • получив команду от клиента, сервер обрабатывает её сразу (а не планирует обработку через async)
    • отправку сообщения клиенту (клиентам) сервер осуществляет асинхронно
  • Широковещательные сообщения от сервера клиентам:
    • сообщения о "знаковых событиях" сервер рассылает всем клиентам, в духе коровьего чата (где он транслирует всем клиентам полученное от клиента сообщение)
    • знаковые события:
      • атака на монстра (сообщать: кто атаковал (имя пользователя), чем, какого монстра, сколько очков здоровья снёс, сколько о.з. осталось; если монстр убит, то сообщить об этом [чтобы клиентам не пришлось выпарсивать число о.з.]) сколько включая результат)
      • установка монстра (кто поставил, имя монстра, кол-во о.з.)
      • заход пользователя (в т.ч. сообщить имя) в MUD
      • прекращения сеанса пользователя в MUD (тоже с указанием имени)
    • есть и не-широковещательные сообщения, например приветствие от встреченного монстра поступает одному конкретному пользователю
  • Прямого взаимодействия между пользователями нет
  • Возможны логические гонки: например, два пользователя более-менее одновременно отправили команду атаки на одного и того же монстра, "первый" убил монстра, а второму пришло индивидуальное сообщение о том, что монстра нет. Это терпимо.