Сообщение Re[2]: Максимальная длина TCP пакета в сети от 11.02.2020 4:51
Изменено 11.02.2020 4:54 AlexGin
Re[2]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Marty, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
M>Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты
Я — аналогично.
Но сравнивать UART (или RS485) с TCP — не буду. Это нелогично и неверно.
Одно дело — передать 10 байт, причём их всегда десять (ну даже если в 2-3 раза больше — обычно длина константна).
Совсем другое — массив длиной от 10 байт до 10 килобайт.
M>Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй
Да вроде как здесь выше сообщалось, что КС в подсистеме TCP проверяется "под_капотом"...
M>Здравствуйте, AlexGin, Вы писали:
M>Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты
Я — аналогично.
Но сравнивать UART (или RS485) с TCP — не буду. Это нелогично и неверно.
Одно дело — передать 10 байт, причём их всегда десять (ну даже если в 2-3 раза больше — обычно длина константна).
Совсем другое — массив длиной от 10 байт до 10 килобайт.
M>Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй
Да вроде как здесь выше сообщалось, что КС в подсистеме TCP проверяется "под_капотом"...
Re[2]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Marty, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
M>Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты
Я — аналогично.
Но сравнивать UART (или RS485) с TCP — не буду. Это нелогично и неверно.
Одно дело — передать 10 байт, причём их всегда десять (ну даже если в 2-3 раза больше — обычно длина константна).
Совсем другое — массив длиной от 10 байт до 10 килобайт.
Причём, если раньше в моих же проектах блок данных (пакет прикладного уровня) на TCP исчерпывался 256 байт фикс-длины,
то также никаких траблов замечено не было.
M>Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй
Да вроде как здесь выше сообщалось, что КС в подсистеме TCP проверяется "под_капотом"...
M>Здравствуйте, AlexGin, Вы писали:
M>Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты
Я — аналогично.
Но сравнивать UART (или RS485) с TCP — не буду. Это нелогично и неверно.
Одно дело — передать 10 байт, причём их всегда десять (ну даже если в 2-3 раза больше — обычно длина константна).
Совсем другое — массив длиной от 10 байт до 10 килобайт.
Причём, если раньше в моих же проектах блок данных (пакет прикладного уровня) на TCP исчерпывался 256 байт фикс-длины,
то также никаких траблов замечено не было.
M>Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй
Да вроде как здесь выше сообщалось, что КС в подсистеме TCP проверяется "под_капотом"...