Решил создать новый протокол на основе udp.
Преимущества:
* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их.
* управление разрывами, UDP уже порван, и разрывы ему не страшны.
* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки.
+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Из проблем организовываются:
* потребуется взять на себя часть функций системы и рулить всем этим делом.
Возникающие вопросы:
* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно?
* (Было что-то еще, надеюсь вспомню по ходу обсуждения, если таковое состоится. )
Также хотелось бы услышать ваше мнение обо всей этой затее.
Было бы неплохо обсудить саму техническую сторону. вопросов с организацией много, и мозги соображают достаточно медленно.
Так же уже видны проблемы в безопасности(в основном при подделке пакетов), что радости не добавляет.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp.
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
Для начала неплохо было бы определиться с предназначением протокола,
потом ознакомиться с уже существующими.
И только потом, по всей видимости, станет ясно, что все возможные велосипеды
в этой области уже придуманы и разработаны. Но сам процесс познания этой области
весьма полезен.
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp.
MSV>Возникающие вопросы: MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
Из того, что вы очень смутно перечислили, я понял, что по сети всё-таки будут гулять UDP пакеты, а вы просто будете писать в них дополнительную служебную информацию и своей библиотекой её обрабатывать. Маршрутизаторы, в данном случае, видят обычные UDP пакеты. Точно так же, как маршрутизаторам пофиг на HTTP: они видят обычные TCP пакеты.
MSV>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно?
CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
maxp вам выше правильно написал, что все велосипеды уже изобретены, но для исследования — конечно, нормальная затея. Только написав свой велосипед можно понять достоинства и недостатки чужих.
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 вам выше правильно написал, что все велосипеды уже изобретены, но для исследования — конечно, нормальная затея. Только написав свой велосипед можно понять достоинства и недостатки чужих.
мой велосипед еще не изобретен А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
MSV>>>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
T>>Из того, что вы очень смутно перечислили, я понял, что по сети всё-таки будут гулять UDP пакеты, а вы просто будете писать в них дополнительную служебную информацию и своей библиотекой её обрабатывать. Маршрутизаторы, в данном случае, видят обычные UDP пакеты. Точно так же, как маршрутизаторам пофиг на HTTP: они видят обычные TCP пакеты. MSV>Вы кажется не поняли вопроса, вопрос был в разнице поведения маршрутизаторов при tcp и udp. MSV>На данный момент я не знаю, как долго на маршрутизаторе будет открыт порт для udp соединения. (потестирую, когда напишу первый вариант протокола.)
Нет такого понятия "как долго открыт порт". Если речь о файрволе, то он открыт, пока админ его не закроет, то есть пока не создаст правило, по которому пакеты на такой-то порт дропаются или отправителю возвращается отказ (deny).
Если речь о таймаутах, то в UDP их просто нет. UDP — stateless протокол. Нет соединения, нет сессии. Есть просто передача пакетов.
MSV>>>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? T>>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает. MSV>Опять не совсем то, CRC гарантирует правильность заголовка пакета или всего пакета?
Здравствуйте, MikelSV, Вы писали:
MSV>А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
Вам снились? По громкости заявления напоминает Ваше предыдущее сообщение о создании фирмы
Ну, дерзайте. Создадите новый протокол, добавите его в стек, оформите патент и станете вторым Брином.
Здравствуйте, Temoto, Вы писали:
T>Нет такого понятия "как долго открыт порт". Если речь о файрволе, то он открыт, пока админ его не закроет, то есть пока не создаст правило, по которому пакеты на такой-то порт дропаются или отправителю возвращается отказ (deny). T>Если речь о таймаутах, то в UDP их просто нет. UDP — stateless протокол. Нет соединения, нет сессии. Есть просто передача пакетов.
Но порт то все равно открывается, на маршрутизаторе, типа NAT.
И маршрутизатор(NAT) воспринимает это как соединение, помнит, куда пересылать пакеты приходящие из интернета на этот порт.
меня беспокоит то, что посланный мне пакет будет отброшен из-за закрытия порта на маршрутизаторе по таймауту.
T>Заголовка и содержимого.
T>Вы бы почитали с чем будете работать, что-ли. Хотя бы на википедии, я уж не говорю про RFC768. T>http://en.wikipedia.org/wiki/User_Datagram_Protocol
Читал, но насчет CRC не совсем понял. ^_^
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Здравствуйте, Temoto, Вы писали:
T>>Нет такого понятия "как долго открыт порт". Если речь о файрволе, то он открыт, пока админ его не закроет, то есть пока не создаст правило, по которому пакеты на такой-то порт дропаются или отправителю возвращается отказ (deny). T>>Если речь о таймаутах, то в UDP их просто нет. UDP — stateless протокол. Нет соединения, нет сессии. Есть просто передача пакетов.
MSV>Но порт то все равно открывается, на маршрутизаторе, типа NAT. MSV>И маршрутизатор(NAT) воспринимает это как соединение, помнит, куда пересылать пакеты приходящие из интернета на этот порт. MSV>меня беспокоит то, что посланный мне пакет будет отброшен из-за закрытия порта на маршрутизаторе по таймауту.
Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
T>>Заголовка и содержимого.
T>>Вы бы почитали с чем будете работать, что-ли. Хотя бы на википедии, я уж не говорю про RFC768. T>>http://en.wikipedia.org/wiki/User_Datagram_Protocol MSV>Читал, но насчет CRC не совсем понял. ^_^
[q]UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload.[q]
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, MikelSV, Вы писали:
MSV>>А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
А>Вам снились? По громкости заявления напоминает Ваше предыдущее сообщение о создании фирмы А>Ну, дерзайте. Создадите новый протокол, добавите его в стек, оформите патент и станете вторым Брином.
Опа, это который основатель гугла?
Ну реально интересные вещи, повесить на этот протокол HTTP. А так же методом пробивания ната создать сайт на закрытом динамическом ip.
Немного ушел в депрессию, чтобы выйти из нее занялся новой идеей. ^_^
Кстати, что значит добавить его в стек? (Стек протоколов полагаю.) Тоесть как?
Не вижу особого смысла. максимум, это создание в виде библиотеки.
И протокол не совсем похож на стандартные. планируется дополнительный поток. А сейчас кажется даже несколько.(для создания многопоточного сервера)
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, Temoto, Вы писали:
T>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Хм, простой пример. DNS запрос, через UDP, который пройдет через нат.
Ответ приходит, значит в маршрутизаторе создалась сессия и он помнит, куда надо слать пакеты приходящие на тот порт.
T>Серьёзно, не понял?
Читал русский вариант.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Здравствуйте, Temoto, Вы писали:
T>>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
MSV>Хм, простой пример. DNS запрос, через UDP, который пройдет через нат. MSV>Ответ приходит, значит в маршрутизаторе создалась сессия и он помнит, куда надо слать пакеты приходящие на тот порт.
Здравствуйте, MikelSV, Вы писали:
MSV>Преимущества: MSV>* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их.
Это как? Все равно вам как-то надо ждать прибывающего пакета. Единственная разница, в случае UDP короткое сообщение придет сразу целиком, а не частями, как в TCP.
Кстати, не советую очень-то рассчитывать на то, что большие фрагментированные UDP-пакеты будут свободно шнырять по всему Интернету. Запросто можете нарваться на роутер между вами и другой стороной, который будет их выкидывать при достижении некоторого (не слишком большого) предельного размера.
MSV>* управление разрывами, UDP уже порван, и разрывы ему не страшны.
Зато пакеты могут теряться, дуплицироваться и приходить не в том порядке, в котором они были посланы.
MSV>* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки. MSV>+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Вам стоит посмотреть на SCTP. Он, правда, к сожалению не входит в стандартную венду...
MSV>Из проблем организовываются: MSV>* потребуется взять на себя часть функций системы и рулить всем этим делом.
Довольно изрядную часть. Осилите?
MSV>Возникающие вопросы: MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении?
Домашнему роутеру более-менее все равно, если вы только не создаете новую пару внутренний порт/внешний адрес на каждый пакет. В последнем случае NAT'овская таблица быстро переполнится. Но во многих корпоративных сетях выход UDP наружу может быть закрыт, в то время как TCP доступен в более-менее либеральном режиме.
MSV>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? MSV>* (Было что-то еще, надеюсь вспомню по ходу обсуждения, если таковое состоится. )
Контрольная сумма в UDP используется в точности такая же, как и в TCP. С единственным отличием: в UDP она является опциональной и при отправке пакета может быть отключена (физически при этом в пакете вместо контрольной суммы 0, что воспринимается принимающей стороной как просьба контрольную сумму не проверять).
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
Дурацкая затея
Сначала определитесь с тем, какие проблемы вы собираетесь решать, потом уже выбирайте методы решения.
Здравствуйте, Temoto, Вы писали:
T>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Для UDP есть NAT, причем обычнуе роутеры в среднем его поддерживают. Сессии как таковой нет, но роутер просто хранит в таблице в течении некоторого времени запись о том, что такой-то внутренний адрес:порт соответствует такому-то внешнему. Если в течении этого времени через такую ассоциацию траффика нет, ассоциация сгорает и освобождает место в таблице. Чтобы дырка в NAT'е не "заростала", достаточно посылать туда-обратно пакетик с некоторой периодичностью. Скажем, раз в минуту.
Кстати, в случае TCP все то же самое. Роутер не может рассчитывать на то, что ваш компутер вежливо позакрывает все сессии. Иначе в случае выключения компутера записи в таблице NAT'а болтались бы до морковкина заговения. Просто в случае TCP роутер может, увидив закрытие соединения, выкинуть запись из таблице раньше, не дожидаясь таймаута.
Здравствуйте, MikelSV, Вы писали:
MSV>Ну реально интересные вещи, повесить на этот протокол HTTP. А так же методом пробивания ната создать сайт на закрытом динамическом ip.
Пробивание ната требует координированных усилих двух сторон. Поэтому обычным бровсером на такой сайт не придешь, бровсер должен быть со встроенной натопробивалкой.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Temoto, Вы писали:
T>>Нет NAT для UDP, потому что нет сессии. Нет таймаутов. Почему вы продолжаете их придумывать?
Pzz>Для UDP есть NAT, причем обычнуе роутеры в среднем его поддерживают. Сессии как таковой нет, но роутер просто хранит в таблице в течении некоторого времени запись о том, что такой-то внутренний адрес:порт соответствует такому-то внешнему. Если в течении этого времени через такую ассоциацию траффика нет, ассоциация сгорает и освобождает место в таблице. Чтобы дырка в NAT'е не "заростала", достаточно посылать туда-обратно пакетик с некоторой периодичностью. Скажем, раз в минуту.
Pzz>Кстати, в случае TCP все то же самое. Роутер не может рассчитывать на то, что ваш компутер вежливо позакрывает все сессии. Иначе в случае выключения компутера записи в таблице NAT'а болтались бы до морковкина заговения. Просто в случае TCP роутер может, увидив закрытие соединения, выкинуть запись из таблице раньше, не дожидаясь таймаута.
Здравствуйте, MikelSV, Вы писали:
MSV>Решил создать новый протокол на основе udp.
Решил изобрести свой велосипед...
MSV>Преимущества: MSV>* можно выкинуть select, и любые другие проверки. получение данных сразу по прибытию их. MSV>* управление разрывами, UDP уже порван, и разрывы ему не страшны. MSV>* больший контроль соединения, управление разрывами, появляется возможность посылки разных данных, как потока, так и сообщений. так же есть идея приделать возможность посылки пакетов, не требующих подтверждения доставки. MSV>+ очень заманчивые перспективы, появляется много идей, которые просто невозможны на tcp, управляемом системой.
Ну да конечно, всё здорово и замечательно. А TCP лет 30 не менялся просто потому, что вокруг одни такие недогадливые дураки. И UDP примерно по той же причине существует (равно как и realiable UDP в RFC) -- дураки не понимают...
И через с натами фаерволы новый протокол сам волшебно как-то проникать начнёт...
MSV>Из проблем организовываются: MSV>* потребуется взять на себя часть функций системы и рулить всем этим делом.
Ну на фоне разработки собственноог протокола -- это вовсе не проблема. И реализуется это вовсе очень известным даже способом, на sourceforge есть миллионы и миллиарды студенческих программ это осуществляющих (raw socket).
MSV>* Все ли маршрутизаторы потянут такой неразрывный udp? то есть сколько времени они будут помнить об этом соединении? MSV>* Требуется ли проверять UDP пакет? или его CRC гарантирует, что данные тоже доставлены правильно? MSV>* (Было что-то еще, надеюсь вспомню по ходу обсуждения, если таковое состоится. )
Судя по вопросам, вам бы эта, хоть Стивенса почитать для начала.
MSV>Также хотелось бы услышать ваше мнение обо всей этой затее.
Здравствуйте, Temoto, Вы писали:
T>CRC даёт хорошую защиту от сбоев оборудования. От преднамеренного изменения пакетов "человеком-посередине" не защищает.
Жизненный опыт. CRC даёт хреновейшую защиту от "сбоев оборудования" при обрыве, когда с середины пакета и до конца все байты FFFF или 0000 не важно. А контрольная сумма замечательно работает. Кто-то всерьёз полагает, что бред повсеместно приведённый в некоторой литературе, что дескать CRC не используется в TCP/IP ровно потому, что его трудно считать? Нет, он тривиально считается в аппаратуре, побитно...
Хмм, может быть. Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Простенькие вещи, типа пинга, возврата ip адреса и номера порта и возврата времени я приделал. они не требуют создания сессий и гоняются легко.
Наверно займусь сообщениями, для них тоже можно не делать виртуальных сессий, они как бы глобальные для соединения.
хм, и сдается мне на этом нужно закончить. полагаю будет сообщение с данными, то есть, в моем протоколе над tcp, (который я написал раньше), заложена возможность посылки набора сообщений, достаточных для работы с файлами: открытие, запись, чтение... потоки данных станут не более чем файлами. кстати, уже очень давно у меня есть код, позволяющий работать с виртуальными файлами внутри одной программы, а так же монтирование папок. К сожалению это все сделано внутри одной программы, до монтирования в систему я не дошел. В итоге, можно получать доступ к файлам на других компьютерах и вообще к любым источникам данных, как к обычным файлам на локальном компьютере. А если вам не нравится чистый поток, можно воспользоваться контейнером и погрузить туда данные в формате: ключ, значение. а для особых любителей извращений можно воспользоваться им для аналогичной передачи данных как в xml, с той же структурой.
В общем, белой и горячей у меня еще много.
Правда пожалуй кое что не доработано, это адресация. В размышлениях о которой я так и не пришел к хорошему решению.
Однако в данном случае адресация упадет до вида: ip:порт, что и решит все проблемы с ней.
Итого: данный протокол позволяет решить много различных проблем. И в случае успешной реализации позволят создавать готовые решения в передаче структурированных данных. (А стандартные протоколы, такие как HTTP и FTP можно легко переделать с использованием нового протокола.)
Вот такая вот она белая и пушистая и конечно же горячая.
Римское правило. Тот, кто говорит, что Это не может быть сделано, никогда не должен мешать тому, кто Это делает.
Осень, ну вы поняли.
Зачем еще один код? А человек?
Здравствуйте, MikelSV, Вы писали:
MSV>Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Не вижу ничего противоестественного в такой реализации.
Здравствуйте, MikelSV, Вы писали:
fk0>> Бред в состоянии белой горячки.
MSV>Хмм, может быть. Я тут понял, что хочу через один порт гонять много отдельных потоков. Вот это действительно белая горячка, когда через 2 реальных соккета будут гоняться толпы виртуальных соединений.
Ну а в чём проблема-то? Есть такие реализации. А вообще передать в начале сообщения номер виртуального потока — стоит копейки, а пользы целые вагоны. (Если это вообще нужно)
MSV>Простенькие вещи, типа пинга, возврата ip адреса и номера порта и возврата времени я приделал. они не требуют создания сессий и гоняются легко. MSV>Наверно займусь сообщениями, для них тоже можно не делать виртуальных сессий, они как бы глобальные для соединения.
Как только станет вопрос об адресации получателя сообщения, возникнет тот же самый идентификатор соединения (или сессии, в зависимости от стиля терминологии). Отличие будет только в том, где и как он выглядит.
MSV>В общем, белой и горячей у меня еще много.
Согласен.:) Вы даже если тут сделали что-то полезное — слишком сумбурно объясняете, чтобы можно было понять и оценить результат.
А вообще, этом протоколе я увидел такие возможности, которые до сих пор только снились.
