TFTP (Trivial File Transfer Protocol) - очень удобный и легкий протокол для передачи данных между хостами по UDP.Это описано в RFC 1350. Мне это нравится, и я использую его для управления устройствами.
Одна вещь, которую он делает, вызывает у меня немного головной боли: он меняет порты во время установления соединения.Клиент отправляет свой начальный пакет (запрос на чтение или запись) на порт 69 на сервере, используя случайный номер порта источника (назовите его «n»).Затем сервер отправляет обратно пакет (пакет данных или ack соответственно) на порт 'n', используя свой собственный произвольный номер порта источника (назовите его «m»).Схематически происходит следующее:
Client Server
[ IP1,IP2,n,69,RRQ/WRQ ] ---->
<---- [ IP2,IP1,m,n,ACK/DATA ]
Моя проблема заключается в том, что ответный пакет сервера приходит слишком быстро на мою клиентскую машину: у него еще не было возможности начать прослушивание порта 'n',Видите ли, сокеты, необходимые для отправки первого пакета, не могут быть теми же сокетами, которые необходимы для приема второго пакета - связанные номера портов отличаются!Поэтому после отправки первого пакета я должен закрыть первый сокет, создать второй сокет и начать прослушивать его.Это требует времени.Кажется, слишком много времени, потому что к тому времени, когда второй сокет в конце концов прослушивает, ответный пакет сервера уже прошел мимо меня.Мои вопросы:
Кто-нибудь видел эту проблему раньше (вы должны, например, реализовать TFTP только с необработанными сокетами)?
Будет лисоздание второго сокета и прослушивание его, например, в другом потоке, перед первым и использование SO_REUSEADDR или справки SO_REUSEPORT?
Есть ли другой способ изменить первый сокет,чтобы «убрать» его из исходного обозначения порта-69, чтобы я мог повторно использовать его для прослушивания и при этом использовать только один разъем?
Спасибо!