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

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

• HTTP-сервер для бедных:

  • python3 -m http.server

  • Посмотреть на http://localhost:8000

  • Простой способ узнать IP, если работает DNS:

       1 import socket
       2 socket.gethostbyname(socket.gethostname())
    

  • Если DNS не работает или hostname == "localhost":

       1 import socket
       2 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
       3 s.connect(("8.8.8.8", 80))
       4 print(s.getsockname()[0])
       5 s.close()
    

    • Пояснение: .connect() для UDP-сокета настраивает поле адрес_отправителя:порт_отправителя, но собственно соединения не устанавливает. адрес_отправителя при этом определяется маршрутизацией — это IP того интерфейса, через который пойдёт передача.

• HTTP-сервер, который выводит IP адрес, а не 0.0.0.0

  • Изучить Модуль http.server

    • Подсказка: нужна только функция test()

  • Написать простой http-сервер httpsrv.py порт, который:

    • Принимает единственный параметр — порт

    • При старте вместо http://0.0.0.0:8000/ выводит найденный IP (чтобы поделиться с товарищами)

  • Подсказки — параметры функции test():

    • BaseHTTPRequestHandler не достаточно, нужен SimpleHTTPRequestHandler

    • port — порт

    • bind — адрес

    • ServerClass.address_family можно не трогать

  • Проверить, работает ли: скачать файл из каталога

• Групповая разработка: precious source + committer

  0. Разбиться на пары. Каждый человек в паре вовлечён в два процесса:
     1. «Разработка собственного проекта» (публикация precious source и приём pull request-ов)
     2. «Участие в проекте товарища» (публикация доработок и отправка pull request-ов)

     3. FIXME: в пошаговой инструкции ниже перемешаны шаги двух процессов ("от клиента" и "от сервера"), люди массово путаются.

  1. Публикация собственного репозитория

     • Создать пустой bare репозиторий public/myrepo (+посмотреть, как он устроен)

          1 $ git init --bare public/myrepo
          2 $ ls public/myrepo
       

     • Настроить репозиторий для публикации (скопировать или переименовать хук, который будет запускаться при обновлении, заодно глянуть внутрь него — там должна запускаться команда git update-server-info). ВНИМАНИЕ: если про хук забыть, репозиторий не получится склонировать по HTTP — git будет отвечать "not found", хотя в браузере репозиторий по тому же адресу виден.

          1 $ cp public/myrepo/hooks/post-update.sample public/myrepo/hooks/post-update
          2 $ cat public/myrepo/.git/hooks/post-update
          3 …
          4 exec git update-server-info
          5 
       

     • Опубликовать с помощью httpsrv.py каталог public (с репозиторием myrepo + на следующем этапе там появится hisrepo)

     • Открыть новый терминал. Склонировать public/myrepo (не по http, потому что нужен доступ на запись)

          1 $ git clone public/myrepo myrepo
       

     • Сделать в myrepo какие-то изменения (например, скопировать туда файл httpsrv.py), закоммитить и запушить

     • Сообщить адрес, порт и имя опубликованного репозитория товарищу

  2. Публикация изменений для чужого репозитория

     • Узнать у товарища адрес, порт и имя его публичного репозитория

     • По аналогии с предыдущим создать пустой bare репозиторий public/hisrepo и настроить в нём hooks/post-update

     • Склонировать public/hisrepo в hisrepo

     • Добавить репозиторий товарища в качестве второго remote:

          1 [hisrepo] $ git remote add upstream http://адрес.товарища:порт_товарища/myrepo
          2 hisrepo$ git remote -v
          3 
       

     • Помержить пустую историю с авторской, добавить какие-то изменения, закоммитить:

          1 hisrepo$ git pull upstream master
          2 hisrepo$ # …hack-hack-hack
          3 hisrepo$ git add .
          4 hisrepo$ git commit -a -m "Very useful fix"
          5 
       

     • Результат пометить аннотированным тегом "fixes" и запушить в public/hisrepo

          1 hisrepo$ git tag fixes -a -m "Some fixes"
          2 hisrepo$ git push --tags
          3 
       

  3. Зарегистрироваться как коммиттер в репозитории товарища и зарегистрировать товарища как коммиттера
     • Сообщить товарищу адрес, порт и имя репозитория, в котором вы опубликовали изменения и узнать у него ту же информацию

     • В своём репозитории добавить в качестве второго remote репозиторий с изменениями от товарища:

          1 myrepo$ git remote add committer http://адрес.товарища:порт_товарища/hisrepo
          2 myrepo$ git remote update
          3 
       

  4. Принять и отправить pull-реквест!
     • Узнать у товарища имя тега, помечающего обновления и сообщить ему имя своего аналогичного тега

          1 myrepo$ git remote update
          2 …
          3  * [new tag]         fixes      -> fixes
          4 myrepo$ git merge fixes
          5 
       

• С помощью git log убедиться, что изменения пришли, опубликовать их и т. д.

Обратите внимание на то, что информационный обмен шёл не через git

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

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

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

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

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

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

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

Д/З

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

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

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

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

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

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

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

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