Могу ли я доверять сегменту TCP с полезной нагрузкой в 255 байтов, который будет доставлен в одном кадре Ethernet?
Я пишу серверное программное обеспечение, которое обновляет прошивку электронного устройства. Это непростая задача, потому что в настоящее время у этих устройств недостаточно памяти для хранения полной прошивки перед ее установкой. В результате мой сервер переключит устройство в режим загрузчика и проинструктирует загрузчик, что делать, отправив инструкции и данные прошивки по сети. Как вы понимаете, у этого есть несколько потенциально серьезных недостатков.
В данный момент меня беспокоит, будет ли один сегмент TCP, который я отправляю, разделить на несколько кадров Ethernet?
Из-за природы загрузчика максимальный размер полезной нагрузки, которую я могу отправить в сегменте TCP, составляет 255 байтов.
Из захвата пакетов в Wireshark кажется, что размер кадра для кадра, содержащего один из моих TCP-сегментов, составляет 309 байтов (2472 бит), что находится в пределах допустимого диапазона согласно странице Википедии на Кадры Ethernet :
В настоящее время я пытаюсь справиться с тем, что произойдет, если соединение с устройством разорвано. В настоящее время у меня нет проблем с восстановлением соединения с устройством, но я хочу быть уверенным в том, что произойдет после восстановления соединения.
Если я могу быть уверен, что каждая инструкция всегда будет содержаться в одном кадре Ethernet и как таковая будет либо доставлена, либо не будет доставлена, тогда счастливых дней! Я могу посмотреть последнюю отправленную инструкцию и решить, что делать дальше.
Однако, если есть возможность, что инструкция может быть разделена на два кадра Ethernet, у меня есть гораздо большая проблема. Я не думаю, что это должно произойти, но иногда кажется, что это происходит, когда я тестирую.
Скажем, я выполнил команду записи, а загрузчик ожидает записи данных, я отправляю свой TCP-сегмент с 255 байтами, и он разделяется на два кадра Ethernet. Первый кадр доставляется, а второй - нет. Теперь, когда я снова подключаюсь, мне нужно точно определить, сколько байтов загрузчик уже получил, а это значит, что мне нужно отправить фиктивные данные и прослушать ответ. Я бы очень хотел этого избежать, если возможно.
Читая комментарии в эта тема, похоже, что IP-пакеты размером менее 576 байт (4 608 бит) не будут разделены. Могу ли я предположить, что так будет всегда?
На самом деле, если он разделен, модуль WiFi не должен доставлять сегмент TCP, пока он не будет повторно собран, не так ли? И он будет отброшен, если соединение будет потеряно.
В общем, очень сложно контролировать, разделен пакет или нет. На самом деле вам нужно будет очень глубоко погрузиться в стек - такие вещи, как разгрузка TCP на оборудование, также могут мешать и создавать пакеты, оптимизированные для транспортировки.
Но вы говорите о TCP-соединении, поэтому не должно быть никаких проблем, если ваше соединение имеет короткое прерывание. Если один пакет TCP разделяется на несколько пакетов Ethernet и ваше соединение прерывается (на короткий момент) между передачей одного кадра, TCP попытается передать пакет (который является частью протокола).
При более длительном / обнаруженном отключении гораздо более серьезной проблемой будет тот факт, что вы не можете просто продолжить отправку, не восстановив новое соединение (для которого ваше устройство должно поддерживать это) - настройка нового сокета и отправка на тот же удаленный хост без TCP syn / ack, вероятно, не поддерживается никаким стеком по умолчанию.
Что касается вашей желаемой цели (если возможно), я бы порекомендовал иметь надлежащий способ обработки прерываний во время обновления прошивки (например, двойной загрузки).
Если это невозможно, и вы не реализуете свой собственный стек TCP / IP, я просто могу порекомендовать отключить любое аппаратное ускорение на вашем сервере (чтобы предотвратить повторную сборку ваших пакетов оборудованием) и отключить алгоритм нагла на вашем сокетном соединении.