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, возможно, хватит времени ещё на что-нибудь!
Д/З
Задача_1. Многопользовательский MUD (multiuser multiuser dungeon) Скопируйте решение Задачи_1 с предыдущего занятия. Сделайте коммит. Работайте на ветке work.
- Сделайте (наконец-то!) MUD многопользовательским. Подробности ниже.
- Многосессионность (поддержку работы с одним сервером одновременно нескольких клиентов) реализуйте по схеме "коровьего чата" из лекций.
- Именованные сеансы:
При подключении клиента к серверу, клиент передаёт серверу имя пользователя (строка без пробелов, поступает клиенту при запуске - python mymud.py username).
- Сервер проверяет, что подключенного пользователя с таким именем ещё нет; если есть - отказывает в подключении; если нет, то создает подключение (сообщая об этом клиенту) и запоминает имя пользователя.
- Асинхронность работы клиента с сервером:
- после отправки сообщения серверу, клиент НЕ ждёт ответа от сервера
- все сообщения от сервера клиенту _после_ успешного подключения - "асинхронные", т.е. принимаются параллельно работе пользователя с командной строкой
все сообщения от сервера клиенту предназначены для вывода "as is", никакого разбора в духе "набор параметров от сервера к клиенту" теперь не нужно; т.е. клиент отправляет команды на сервер без ожидания ответа и без "понимания", что сообщения от сервера приходят в ответ на конкретные команды
схема параллельного ожидания сообщений и обработки пользовательского ввода - см. лекцию (раздел "Cmd и асинхронные сообщения")
- важно: после получения от сервера (и вывода) сообщения, клиент должен показать командную строку с набранным (но не введённым) пользователем текстом, чтобы результат ввода не исчезал (опять см. лекцию)
- Частичная неделимость обработки пользовательской команды на сервере (для ограничения гонок):
- помним, что сервер последовательный
- получив команду от клиента, сервер обрабатывает её сразу (а не планирует обработку через async)
- отправку сообщения клиенту (клиентам) сервер осуществляет асинхронно
- Широковещательные сообщения от сервера клиентам:
- сообщения о "знаковых событиях" сервер рассылает всем клиентам, в духе коровьего чата (где он транслирует всем клиентам полученное от клиента сообщение)
- знаковые события:
- атака на монстра (сообщать: кто атаковал (имя пользователя), чем, какого монстра, сколько очков здоровья снёс, сколько о.з. осталось; если монстр убит, то сообщить об этом [чтобы клиентам не пришлось выпарсивать число о.з.]) сколько включая результат)
- установка монстра (кто поставил, имя монстра, кол-во о.з.)
- заход пользователя (в т.ч. сообщить имя) в MUD
- прекращения сеанса пользователя в MUD (тоже с указанием имени)
- есть и не-широковещательные сообщения, например приветствие от встреченного монстра поступает одному конкретному пользователю
- Прямого взаимодействия между пользователями нет
- Возможны логические гонки: например, два пользователя более-менее одновременно отправили команду атаки на одного и того же монстра, "первый" убил монстра, а второму пришло индивидуальное сообщение о том, что монстра нет. Это терпимо.
