Технологии компьютерных сетей весна 2018 — различия между версиями

Материал из SEWiki
Перейти к: навигация, поиск
м
(Задание 2)
 
(не показаны 2 промежуточные версии этого же участника)
Строка 16: Строка 16:
  
 
Порядок выполнения:
 
Порядок выполнения:
# Сделать форк [https://github.com/h31/ProgrammingLabTask1 репозитория] на GitHub.
+
# Сделать форк [https://github.com/h31/NetworksLab2018AU репозитория] на GitHub.
 
# Для каждого задания сделать отдельную ветку (branch) в своём репозитории.
 
# Для каждого задания сделать отдельную ветку (branch) в своём репозитории.
 
# Работать над кодом, сохраняя файлы в соответствующей заданию директории.
 
# Работать над кодом, сохраняя файлы в соответствующей заданию директории.
Строка 42: Строка 42:
 
* Сервер не знает о длине получаемых сообщений.
 
* Сервер не знает о длине получаемых сообщений.
  
Язык программирования - Си. Для сборки кода используйте утилиту CMake. Для организации работы с несколькими клиентами используйте потоки, pthreads в Linux/BSD/macOS и WinAPI в Windows. Не забывайте использовать примитивы синхронизации для блокировки общих между несколькими клиентами ресурсов.
+
Язык программирования - С или C++. Для сборки кода используйте утилиту CMake. Для организации работы с несколькими клиентами используйте потоки. Не забывайте использовать примитивы синхронизации для блокировки общих между несколькими клиентами ресурсов.
  
 
Результатом выполнения задания должно быть 4 программы, клиент и сервер под Windows и Linux/BSD/macOS, и описание вашего прикладного протокола. Протокол можно описать либо с помощью текста, либо с помощью изображений (таблицы, схемы и т.д.). Примеры описания протоколов - в слайдах лекций. Описание должно быть в такой степени подробным, чтобы по нему можно было написать альтернативную совместимую реализацию клиента/сервера.
 
Результатом выполнения задания должно быть 4 программы, клиент и сервер под Windows и Linux/BSD/macOS, и описание вашего прикладного протокола. Протокол можно описать либо с помощью текста, либо с помощью изображений (таблицы, схемы и т.д.). Примеры описания протоколов - в слайдах лекций. Описание должно быть в такой степени подробным, чтобы по нему можно было написать альтернативную совместимую реализацию клиента/сервера.
Строка 49: Строка 49:
  
 
Крайний срок выполнения: '''18 марта''' в 23:59. К этому времени необходимо выполнить задание, выложить его на GitHub и сделать Pull Request. Замечания преподавателя '''можно''' исправлять после дедлайна, но учтите, что в таком случае вы будете отнимать у себя время на выполнение следующих заданий.
 
Крайний срок выполнения: '''18 марта''' в 23:59. К этому времени необходимо выполнить задание, выложить его на GitHub и сделать Pull Request. Замечания преподавателя '''можно''' исправлять после дедлайна, но учтите, что в таком случае вы будете отнимать у себя время на выполнение следующих заданий.
 +
 +
=== Задание 2. Простейший UDP-клиент/сервер ===
 +
 +
Необходимо реализовать клиент и сервер протокола DNS.
 +
 +
Отличия относительно предыдущего задания:
 +
* ОС - одна, какая именно - на ваш выбор.
 +
* Не нужно описывать протокол.
 +
 +
Подразумевается, что протокол будет реализован на минимальном рабочем уровне. Рассчитывайте на следующие ограничения:
 +
* Поддержка только записей типа A.
 +
* Сервер может указывать любой адрес в ответе. Это может быть хэш доменного имени, адрес из файла (например, /etc/hosts), случайная величина с seed равным длине доменного имени в запросе или что-то другое на ваш выбор. Единственное пожелание - чтобы возвращаемый адрес был функцией от доменного имени в запросе и указанного файла на локальном компьютере и не зависел бы от других величин (для обеспечения идемпотентности запроса). Также возможна реализация сервера, который бы с помощью вызовов getaddrinfo/gethostbyname запрашивал адреса из реальной DNS-сети.
 +
* В ответе не нужно указывать ни авторитативные сервера, ни дополнительные записи. Только непосредственно ответы.
 +
 +
Для экономии времени можно в качестве шаблона запроса/ответа использовать захваченный сниффером пакет. В Wireshark для этого есть функция Export as C Arrays.
 +
 +
Для проверки разработанного DNS-сервера используйте консольные утилиты host, dig или nslookup, явно указав им обращаться к серверу на том же компьютере. Для проверки DNS-клиента используйте любой существующий DNS-сервер, например, Google Public DNS (8.8.8.8).
 +
 +
[https://tools.ietf.org/html/rfc1035 RFC на протокол DNS]. Кроме того, есть множество упрощенных описаний протокола DNS.
 +
 +
=== План выполнения работ ===
  
 
Текущий план:
 
Текущий план:

Текущая версия на 10:19, 20 марта 2018

Лекции

Преподаватель: Ицыксон Владимир Михайлович (vlad@ftk.spbstu.ru, itsykson@gmail.com)

Практика

Преподаватель: Алексюк Артем Олегович (aleksyuk@kspt.icc.spbstu.ru, artyom.aleksyuk@gmail.com)

Telegram-группа для взаимодействия в ходе курса. Участвовать не обязательно, но очень желательно. В группе будут выкладываться объявления по курсу, кроме того, преподаватель будет по мере возможности отвечать там на вопросы. Основные объявления будут дублироваться в SeWiki.

Задания

Порядок выполнения:

  1. Сделать форк репозитория на GitHub.
  2. Для каждого задания сделать отдельную ветку (branch) в своём репозитории.
  3. Работать над кодом, сохраняя файлы в соответствующей заданию директории.
  4. В тот момент, когда вы будете готовы показать свой код (для проверки или консультации), сделать Pull Request в мою ветку master.
  5. Исправить замечания преподавателя.
  6. Дождаться статуса Approved у вашего Pull Request-а.

Задание 1. Простейший TCP-клиент/сервер (мессенджер Elegram)

Необходимо разработать простейшую систему обмена мгновенными сообщениями (чат, мессенджер). Чат-сервер должен принимать сообщения от клиентов и рассылать полученные сообщения всем подключенным клиентам. У каждого клиента должен быть собственный никнейм, задаваемый пользователем. При получении сообщения от другого клиента, на экран должно выводиться время получения сообщения, никнейм пользователя-отправителя и текст сообщения. Пример вывода: <4:20> [Peter] Hello!

Клиент должен иметь консольный интерфейс. Параметры работы клиент принимает через аргументы командной строки в следующем порядке: адрес сервера, порт, никнейм. Функции, которые не требуются от сервера и клиента:

  • Регистрация клиентов, авторизация, аутентификация.
  • Более чем один канал общения.
  • Хранение истории переписки.
  • Обработка временных зон.
  • Работа с языками, отличными от английского.

Чтобы принимаемые (входящие) сообщения не мешали пользователю вводить свой текст, предлагается включать отдельный режим отправки сообщения, например, при нажатии клавиши m. В этом режиме пользователь вводит своё сообщение, новые сообщения от других пользователей временно не отображаются, после отправки сообщения (по Enter) режим автоматически отключается.

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

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

Язык программирования - С или C++. Для сборки кода используйте утилиту CMake. Для организации работы с несколькими клиентами используйте потоки. Не забывайте использовать примитивы синхронизации для блокировки общих между несколькими клиентами ресурсов.

Результатом выполнения задания должно быть 4 программы, клиент и сервер под Windows и Linux/BSD/macOS, и описание вашего прикладного протокола. Протокол можно описать либо с помощью текста, либо с помощью изображений (таблицы, схемы и т.д.). Примеры описания протоколов - в слайдах лекций. Описание должно быть в такой степени подробным, чтобы по нему можно было написать альтернативную совместимую реализацию клиента/сервера.

Бесплатная виртуальная машина с триальной версией Windows. Для сборки программного кода использовать либо Visual Studio (подойдет Community или Express редакция), либо один из дистрибутивов MinGW. Лично у меня успешно заработал TDM-GCC.

Крайний срок выполнения: 18 марта в 23:59. К этому времени необходимо выполнить задание, выложить его на GitHub и сделать Pull Request. Замечания преподавателя можно исправлять после дедлайна, но учтите, что в таком случае вы будете отнимать у себя время на выполнение следующих заданий.

Задание 2. Простейший UDP-клиент/сервер

Необходимо реализовать клиент и сервер протокола DNS.

Отличия относительно предыдущего задания:

  • ОС - одна, какая именно - на ваш выбор.
  • Не нужно описывать протокол.

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

  • Поддержка только записей типа A.
  • Сервер может указывать любой адрес в ответе. Это может быть хэш доменного имени, адрес из файла (например, /etc/hosts), случайная величина с seed равным длине доменного имени в запросе или что-то другое на ваш выбор. Единственное пожелание - чтобы возвращаемый адрес был функцией от доменного имени в запросе и указанного файла на локальном компьютере и не зависел бы от других величин (для обеспечения идемпотентности запроса). Также возможна реализация сервера, который бы с помощью вызовов getaddrinfo/gethostbyname запрашивал адреса из реальной DNS-сети.
  • В ответе не нужно указывать ни авторитативные сервера, ни дополнительные записи. Только непосредственно ответы.

Для экономии времени можно в качестве шаблона запроса/ответа использовать захваченный сниффером пакет. В Wireshark для этого есть функция Export as C Arrays.

Для проверки разработанного DNS-сервера используйте консольные утилиты host, dig или nslookup, явно указав им обращаться к серверу на том же компьютере. Для проверки DNS-клиента используйте любой существующий DNS-сервер, например, Google Public DNS (8.8.8.8).

RFC на протокол DNS. Кроме того, есть множество упрощенных описаний протокола DNS.

План выполнения работ

Текущий план:

  • До 18 марта - первое задание (2,5 недели).
  • До 28 марта - второе задание (1,5 недели).
  • До 25 апреля - первая часть третьего задания (4 недели).
  • До 23 мая - вторая часть третьего задания (4 недели).

Темы для обсуждения на практических занятиях

  • Администрирование сетевых сервисов
    • HTTP-сервер. Nginx, Apache httpd, особенности, администрирование. HTTP/2, TLS в HTTP-сервере.
    • FastCGI, реверсивные прокси.
    • Файлообменные серверы. FTP, NFS, SFTP, SMB-сервер. Rsync.
    • VPN-сервер. IPsec, OpenVPN, Wireguard. Сравнение, администрирование. Site-to-site. Туннели.
    • SSH-сервер и всё, что он умеет делать. Авторизация по ключам, ssh-agent, проброс портов, VPN и т.д.
    • Почтовый сервер. SMTP, IMAP-сервер.
    • DNS, DHCP-сервер.
  • Администрирование компьютерных сетей
    • IPv6. Настройка, особенности.
    • Настройка сети в GNU/Linux. Старые и новые утилиты. ifconfig, netstat, ip, ss.
    • Утилита tc. Шейпинг трафика, имитация особенностей различных каналов связи.
    • Отладка компьютерных сетей. mtr, traceroute, ping, iperf3.
    • VLAN, коммутация пакетов.
    • NAT, прокси.
    • QoS.
    • AS, looking glass, IX, маршрутизация в Интернете.
    • IGMP.
    • Снифферы. Wireshark, tcpdump. Задание правил.
    • Network Namespaces.
    • InfiniBand.
  • Особенности использования существующих протоколов
    • Протокол TCP. Алгоритмы контроля перегрузок.
    • Задержки в сети. Round trip time т.п.
    • MTU, MSS, фрагментация, туннели.
    • Сериализация данных.