1. Исправить существующий демон, который работает не совсем хорошо. При передачи запроса ARP через RAW сокет, для того, чтобы найти MAC адресс соседнего девайса, ARP запрос теряется и второй девайс его не получает. Как должна происходить коммуникация между нодами в mininet: Клиент отправляет PING запрос к демону через Юникс сокет, демон отправляет ARP broadcast запрос, чтобы найти MAC адресс следующей ноды, получает МАК, записывает его в ARP кеш и отправляет туда МИП запрос с пинг сообщением. Вторая нода получает этот МИП пакет и отправляет ее серверу через юникс сокет, тот возращает PONG сообщение, который проходит через второй демон к первому. Этот демон будет приложен к заказу
Все это реализовано, но надо подправить изначальную отправку и получение ARP сообщение. Второй его почему то не получает
После этого нужно доработать и расширить сетевой стек, реализованный на базе протокола Minimal Interconnection Protocol (MIP), для эмуляции связи между узлами в сети, использующей Mininet. На данном этапе необходимо реализовать маршрутизацию и пересылку сообщений между узлами через промежуточные системы с использованием алгоритма маршрутизации Distance Vector Routing (DVR) Основные задачи: Доработка MIP-демона: • Реализовать маршрутизацию и пересылку данных в MIP сети. • Добавить интерфейс взаимодействия с демоном маршрутизации. • Реализовать механизм пересылки MIP-датаграмм через промежуточные узлы (форвардинг). • Добавить поддержку времени жизни (TTL) для сообщений. Реализация демона маршрутизации: Тип SDU (Service Data Unit) для протокола маршрутизации — 0x04 • Демон должен выполнять две основные функции: запуск протокола маршрутизации (DVR) и обработка запросов маршрутов от MIP-демона. • Протокол должен быть динамическим и использовать метод Poisoned Reverse для предотвращения зацикливания маршрутов. • Реализовать сообщения протокола: 1. HELLO — для обнаружения соседей. 2. UPDATE — для рассылки таблицы маршрутов. 3. REQUEST — для запроса маршрута к конкретному узлу. Формат сообщения REQUEST, используемого для запросов маршрутов (от MIP-демона к демону маршрутизации), выглядит следующим образом: <MIP address of the host itself (8 bits)> <zero (0) TTL (8 bits)> <R (0x52, 8 bits)> <E (0x45, 8 bits)> <Q (0x51, 8 bits)> <MIP address to look up (8 bits)> 4. RESPONSE — для ответа на запрос маршрута. Демон маршрутизации должен отвечать на запросы строго в порядке их получения, используя сообщение RESPONSE со следующим форматом: <MIP address of the host itself (8 bits)> <zero (0) TTL (8 bits)> <R (0x52, 8 bits)> <S (0x53, 8 bits)> <P (0x50, 8 bits)> <next hop MIP address (8 bits)> Чтобы указать на неудачу при поиске маршрута (нет известного маршрута к запрашиваемому узлу), демон маршрутизации ответит с адресом следующего хопа, равным 255. Изменение Ping-приложений: • Обновить клиент и сервер Ping для работы с новым форматом взаимодействия между MIP-демоном и верхними уровнями, в частности поддержка изменения TTL.
Детали реализации: 1. MIP-демон: а. Сокеты: • Демон должен прослушивать RAW-сокет для работы с Ethernet-кадрами. • UNIX-доменный сокет — для взаимодействия с верхними уровнями и демоном маршрутизации. б. Интерфейс с верхними уровнями: • Добавить возможность задания TTL в исходящих сообщениях. • Сообщения через UNIX-сокет должны содержать: MIP-адрес, TTL и полезную нагрузку (SDU). в. Форвардинг: • Если сообщение предназначено не для текущего узла, его TTL уменьшается, и запрос отправляется демону маршрутизации для поиска следующего хопа. • Если маршрут найден, сообщение пересылается следующему узлу с обновленным TTL. • Если маршрута нет или TTL достигает 0, сообщение отбрасывается. 2. Демон маршрутизации: а. Интерфейс взаимодействия с MIP-демоном через UNIX-доменный сокет. б. Протокол маршрутизации: • Реализовать Distance Vector Routing (DVR) с защитой от зацикливания с помощью Poisoned Reverse. • Обновления таблицы маршрутов и обработка запросов на маршрутизацию должны быть асинхронными, чтобы не блокировать работу MIP-демона. в. Форматы сообщений: • REQUEST: Запрос маршрута должен включать MIP-адрес отправителя и адрес искомого узла. • RESPONSE: Ответ на запрос маршрута должен содержать MIP-адрес следующего хопа или 255, если маршрут не найден. 3. Ping-клиент и сервер: o Обновить взаимодействие с MIP-демоном через UNIX-сокет для поддержки нового формата сообщений с TTL. Требования к реализации: 1. Язык программирования: C 2. Среда разработки: Виртуальная машина с Mininet. 3. Сетевой стек: Использование MIP протокола для передачи данных. 4. Маршрутизация: Алгоритм Distance Vector Routing с механизмом Poisoned Reverse.
