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

ВНИМАНИЕ - Упражнения для этого занятия не будут работать под 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

  • TODO: переделать под схему "один человек - одна роль". В каждой паре ОДИН ведущий и ОДИН "товарищ".
  • TODO: четко расписать, что в каком каталоге делать. И в каждом создаваемом публичном репозитории нужно обновлять хуки.
  • TODO: перевести в статус ПАДАВАНКИ, т.к. упражненькой люди не тянут.
  • TODO: возможно, сделать сервер с push-ем.
  • Разбиться на пары. Каждый человек в паре вовлечён в два процесса:
    1. «Разработка собственного проекта» (публикация precious source и приём pull request-ов)
    2. «Участие в проекте товарища» (публикация доработок и отправка pull request-ов)

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

    • Создать пустой bare репозиторий public/aleph (где aleph — это ваше имя латиницей, или какой-то другой id)

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

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

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

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

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

         1 $ git clone public/aleph aleph
      

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

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

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

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

      • Допустим, имя публичного репозитория — beth

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

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

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

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

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

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

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

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

  • Зарегистрироваться как коммиттер в репозитории товарища и зарегистрировать товарища как коммиттера

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

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

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

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

  • Принять и отправить pull-реквест!

    • Узнать у товарища имя тега, которым он пометил обновления к aleph (допустим, это тег fixes)

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

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

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

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

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

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

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

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

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

      • 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 (тоже с указанием имени)
    • есть и не-широковещательные сообщения, например приветствие от встреченного монстра поступает одному конкретному пользователю
  • Прямого взаимодействия между пользователями нет
  • Возможны логические гонки: например, два пользователя более-менее одновременно отправили команду атаки на одного и того же монстра, "первый" убил монстра, а второму пришло индивидуальное сообщение о том, что монстра нет. Это терпимо.