Внедренный стек IP: нормально ли / принято ли иметь асинхронную отправку?

Question

Я пытаюсь реализовать очень маленький стек IP для 8-битных микроконтроллеров AVR. Я не хочу, чтобы он поддерживал TCP, потому что он действительно слишком большой и мне не нужен, а скорее UDP (и, конечно, ARP и ICMP).

Я хочу, чтобы код стека помещался в 16 КБ ПЗУ и 1 КБ ОЗУ, и, конечно, оставлял как можно больше места для приложения. Я использую плату на основе ENC28J60 для управления PHY / MAC, которая имеет внутренний кольцевой буфер RX / TX 8 КБ. Когда пакеты поступают в этот чип, он записывает их один за другим в буфер RX, но не перезаписывает самый старый. На самый старый указатель указывает указатель, который необходимо обновить, чтобы он указывал на следующий пакет, когда пользователь закончит его чтение. Он также отправляет прерывание на один из своих контактов, когда приходит новый пакет.

Для части RX я хочу работать так же, как lwIP: сигнализировать , что новый пакет готов, когда мы получаем прерывание (сохраняем его адрес и размер), но продолжаем его только тогда, когда пользователь вызывает наша функция стека IP. Это должно работать хорошо; если пользователь не вызывает нашу функцию достаточно часто, новые поступающие пакеты будут отброшены и все. Пользователь предоставляет стеку обратный вызов UDP.

Теперь проблема в передаче. Допустим, я хочу отправить пакет UDP на некоторый IP-адрес, для которого я не знаю адрес ссылки. Запрос ARP должен быть отправлен до отправки моего пакета. Что делать, если UDP-пакет приходит до ответа ARP? Это должно быть обработано моим обратным вызовом UDP, но что, если я хочу отправить что-то из этого обратного вызова? Я все еще жду ответа ARP здесь. Наверняка этот механизм блокировки неправильный.

У меня такой вопрос: Это нормально / приемлемо иметь асинхронную отправку? Таким образом, если я хочу что-то отправить, я предоставляю функцию send с обратным вызовом и ее вызывается, когда может быть отправлен пакет UDP , Таким образом, все управляется событиями .

Answer 1

Относительно того, «приемлемо» ли иметь асинхронную отправку, я не могу себе представить, почему это будет проблемой, если вы можете реализовать это в требованиях к размеру кода.

Что касается лучшего способа реализации такой схемы, я не знаю, какой размер пакета вы хотите поддерживать (я предполагаю, что он намного меньше теоретического максимума 64 КБ), но я бы выделил кольцо буферов отправки, и всякий раз, когда процесс, отвечающий за фактическую отправку на аппаратное обеспечение, запускает свой цикл / прерывание / что-либо еще, он проверяет каждый активный буфер на свое состояние ARP (имеет запись ARP, запрос ARP невыполнен, запрос ARP истек, время ожидания ARP отсутствует или запрос невыполнен) и выполните соответствующее действие (соответственно: отправьте на оборудование с соответствующим MAC, пропустите это время, отмените, отправьте запрос ARP). Вы можете запустить эту процедуру отправки каждый раз, когда обновляется таблица ARP, чтобы вы могли удовлетворить любые необходимые требования в режиме реального времени (хотя некоторые люди утверждают, что Ethernet не является и никогда не будет системой, способной работать в реальном времени, но это тема для другого форума, который не против огненных войн).

Answer 2

Можете ли вы иметь два обратных вызова (в основном асинхронные пути), один для получения от уровня IP и один для отправки на IP?

Также, если вы реализуете уровни, я думаю, что функция отправки / маршрутизации IP должна заботиться об ответе ARP на этом уровне.