M>Для начала неплохо было бы определиться с предназначением протокола,
M>потом ознакомиться с уже существующими.
Задача — передача данных и сообщений. создание более удобного протокола чем tcp и больше возможностей управления.
В этом протоколе будет реализована передача сообщений, которые на данный момент передавались по tcp.

M>И только потом, по всей видимости, станет ясно, что все возможные велосипеды
M>в этой области уже придуманы и разработаны. Но сам процесс познания этой области
M>весьма полезен.
Да, эта область открывает много новых и очень интересных возможностей.



MSV>>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?

T>Из того, что вы очень смутно перечислили, я понял, что по сети всё-таки будут гулять UDP пакеты, а вы просто будете писать в них дополнительную служебную информацию и своей библиотекой её обрабатывать. Маршрутизаторы, в данном случае, видят обычные UDP пакеты. Точно так же, как маршрутизаторам пофиг на HTTP: они видят обычные TCP пакеты.
Вы кажется не поняли вопроса, вопрос был в разнице поведения маршрутизаторов при tcp и udp.
На данный момент я не знаю, как долго на маршрутизаторе будет открыт порт для udp соединения. (потестирую, когда напишу первый вариант протокола.)

MSV>>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно?
T>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
Опять не совсем то, CRC гарантирует правильность заголовка пакета или всего пакета?

MSV>>Также хотелось бы услышать ваше мнение обо всей этой затее.
T>maxp вам выше правильно написал, что все велосипеды уже изобретены, но для исследования — конечно, нормальная затея. Только написав свой велосипед можно понять достоинства и недостатки чужих.
мой велосипед еще не изобретен А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.