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

ВНИМАНИЕ - Упражнения для этого занятия не будут работать под 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
1. Разбиться на пары. Работа каждого человека в паре идентична
2. Публикация репозитория
  - Создать пустой bare репозиторий public/myrepo (+посмотреть, как он устроен)
    1 $ git init --bare public/myrepo 2 $ ls public/myrepo
  - Настроить репозиторий для публикации (скопировать или переименовать хук, который будет запускаться при обновлении, заодно глянуть внутрь него — там должна запускаться команда git update-server-info)
    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
  - Открыть новый терминал. Склонировать public/myrepo (не по http, потому что нужен доступ на запись)
    1 $ git clone public/myrepo myrepo
  - Сделать в myrepo какие-то изменения (например, скопировать туда файл httpsrv.py), закоммитить и запушить
  - Сообщить адрес, порт и имя опубликованного репозитория товарищу и узнать у него адрес, порт и имя его публичного репозитория
3. Публичный репозиторий для совместной разработки
  - По аналогии с предыдущим создать пустой bare репозиторий public/hisrepo и настроить в нём hooks/post-update
  - Склонировать public/hisrepo в hisrepo
  - Добавить репозиторий товарища в качестве второго remote:
    1 [hisrepo] $ git remote add upstream http://адрес.товарища:порт_товарища/myrepo 2 hisrepo$ git remote -v 3
  - Помержить пустую историю с авторской, добавить какие-то изменения, закоммитить,i
    1 hisrepo$ git merge upstream 2 hisrepo$ # …hack-hack-hack 3 hisrepo$ git add . 4 hisrepo$ git commit -a -m "more finctions" 5
  - Результат прометить аннотированным тегом "fixes" и запушить к себе в public/hisrepo
    1 hisrepo$ git tag fixes -a -m "Some fixes" 2 hisrepo$ git push --tags 3
4. Зарегистрироваться как коммиттер в репозитории товарища и зарегистрировать товарища как коммиттера
  - Сообщить товарищу адрес, порт и имя репозитория, в котором вы опубликовали изменения и узнать у него ту же информацию
  - В своём репозитории добавить в качестве второго remote репозиторий с изменениями от товарища, и помержиться с ними:
    1 myrepo$ git remote add committer http://адрес.товарища:порт_товарища/hisrepo 2 myrepo$ git remote update 3
5. Принять и отправить pull-реквест!
  - Узнать у товарища имя тега, помечающего обновления и сообщить ему имя своего аналогичного тега
    1 myrepo$ git remote update 2 … 3 * [new tag] fixes -> fixes 4 myrepo$ git merge fixes 5
С помощью git log убедиться, что изменения пришли, опубликовать их и т. д.
Разминка перед многопользовательским 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 (тоже с указанием имени)
  - есть и не-широковещательные сообщения, например приветствие от встреченного монстра поступает одному конкретному пользователю
- Прямого взаимодействия между пользователями нет
- Возможны логические гонки: например, два пользователя более-менее одновременно отправили команду атаки на одного и того же монстра, "первый" убил монстра, а второму пришло индивидуальное сообщение о том, что монстра нет. Это терпимо.

LecturesCMC/PythonDevelopment2024/Prac/06_SocialProject (последним исправлял пользователь FrBrGeorge 2024-04-01 19:25:26)