Средства и методы разработки

Уже сколько таких протоколов изобретали знаешь? Думаешь дураки кругом. Только ничего лучшего чем TCP/IP никак не получается. Посмотри, например, гугловский QUIC. Потом у тебя масса ошибок: 1) стек не послал запрос на потерянное, а не прислал подтверждения на дошедшее -- работает именно так, TCP/IP это протокол использующий ACK-и, а не NACK-и, у последних есть свои другие позитивные и негативные свойства, вообще использование ACK или NACK -- это очень большая тема: https://networkeng …ackexchange.com/a/6925 https://arxiv.org/pdf/1503.02123.pdf Конкретно в случае TCP/IP использование ACK позволяет так же регулировать скорость потока (которая, будучи чрезмерной, приведёт к потере пакетов: потому, что маршрутизаторы не справляющиеся с нагрузкой выкидывают пакеты -- так работает IP сеть вообще). 2) есть понятие selective acknowledgments (https://en.wikiped …ective_acknowledgments), например широко известная паделка финских студентов эту опцию поддерживает практически от рождения, а TCP/IP стеки профессионального уровня, встроенные в модемы, могут не поддерживать и страдать от описанных тобой эффектов (замирание при пропаже пакетов, большие задержки). Хотя надо признать, потеря пакетов вообще плохо действует на TCP/IP несмотря на все подпорки. 3) в "сотовых модемах с не очень качественной связью" на самом деле ничего не теряется, пусть меня поправят если я не прав, но в случае интернета через функцию передачи данных там под низом есть RLP протокол (GSM 04.22 https://www.etsi.o …gsmts_0422v050000p.pdf), над ним есть PPP, и в последнем только IP-пакеты. Потерять там что-то на уровне радиоканала -- сложно. Если используется GPRS, 3G, 4G и т.п. я не знаю как точно, но как-то похоже. Всё потерянное имеет тенденцию доезжать спустя какое-то время. Что прекрасно видно с помощью программы PING. Там не потерянные пакеты -- там пинги запросто задержанные аж на 30 секунд, но пропавших нет. И, следовательно, описанный тобой эффект, где помогает открытие параллельного сокета, скорей глюки самого TCP/IP стека модема. Ещё такой эффект может быть вызван тем, что GPRS-сессия таки разрывалась (и тут уже гарантии целостности потока данных нет), и автоматически восстанавливалась, но при этом нотификация о падении интерфейса не доходила до TCP-стека и не рвала соединения (а в новой сессии и IP-адрес мог быть вообще другой). Но это не проблема TCP/IP, a высокий уровень профессионализма профессиональных встроенных TCP-стеков... 4) Работа UDP совсем не чудо, у UDP есть очень много приложений, где он используется. И если б он не работал, разбежались бы абоненты. И в общем случае проблем с NAT и UDP нет, маршрутизаторы умеют connection tracking для случаев, когда пара IP-адрес и номер порта сохраняются в течении сеанса связи (а не когда запрос на один порт, а ответ на другой рандомный -- тут никто не угадает). И кстати для телематики, это моё мнение, UDP может подходить лучше: не нужно постоянно поддерживать соединение (и отнимать ресурсы у всех причастных). Потерь именно в радиоканале практически нет, но могут быть потери и нарушение очерёдности принятия пакетов в IP-сети. И совершенно не обязательно городить протоколы канального уровня призванные бороться с потерей пакетов, например. Решение этой проблемы можно перенести на уровень приложения: как например, в телефонии, не борются с пропаданием пакетов -- услышать потерянное через пару секунд никому не нужно, проще проиграть предыдущий пакет вместо пропавшего. Если речь про автомобильные трекеры, то текущий статус нет смысла повторять, если потерян. А трек, где машина ездила, конечно должен передаваться без потерь, но там справится протокол уровня X-modem'а или Trivial FTP (TFTP) работающий поверх "ненадёжного" UDP (если спешить некуда, если есть куда, то начинаются ньюансы, и TCP/IP окажется лучше всех самоделок). XOR двух пакетов называется "фонтанное кодирование", на сахаре несколько раз упоминалось. Там возможны более надёжные и практически более интересные схемы, чем RAID-1.