Здравствуйте, lostdnd, Вы писали:
L>Но как быть, если объект разбивается на несколько пакетов при пересылке?
UDP протокол не занимается фрагментацией ( в отличие от TCP, который пытается отсылать данные кусками не превыщающими MTU ). Датаграмма будет фрагментирована средствами IP протокола. И потом на приемном конце также дефрагметирована и передана клиенту уже в собранном виде. Таки образом, вызывая recvfrom в цикле Вы будете получать датаграммы полностью ( если буфера хватит ), в независимости от соотношения длины датаграммы и MTU. Невозможна ситуация получения кусков различных датаграмм. Кроме того, стоит помнить, что есть ограничение на максимальный размер датаграммы.
Здравствуйте.
Нужна помощь в реализации такой задачи:
Узлу на открытый UDP — сокет приходят сериализованные объекты-сообщения. Сообщения могут приходить от разных узлов и для разных обработчиков-плагинов. Грубо говоря есть объект-синглетон, через который плагины подписываться на определенные типы сообщений. Если бы объекты укладывались в рамки MTU, то все просто: ждем очередную датаграмму и далее сразу же ее обрабатываем. Но как быть, если объект разбивается на несколько пакетов при пересылке?
То есть возможна ситуация перемешивания пакетов от разных сообщений. В принципе есть решение снабжать каждое сообщение уникальным идентификатором и организовать очередь для частично принятых сообщений. Но не хочется городить велосипед, наверняка есть готовые решения, примеры реализации, паттерны. В случае отдельного соединения TCP для каждой пары узлов, все довольно просто решается. Но TCP не подходит из-за соображений производительности и проблемы с обходом NAT'ов.
Здравствуйте, lostdnd, Вы писали:
L>Но как быть, если объект разбивается на несколько пакетов при пересылке?
Фигасе обьект >64K... Вы уверены что протокол UDP был выбран правильно?
L>Но TCP не подходит из-за соображений производительности и проблемы с обходом NAT'ов.
О какой производительности (точнее, издержках TCP) идет речь при таких больших обьектах?
Ну а аргумент про NAT'ы совсем непонятен. В случае TCP наружу должен торчать только сервер, в случае UDP — оба конца. Где в случае UDP отсутствие проблемы с NAT'ами?
Здравствуйте, Michael Chelnokov, Вы писали:
MC>О какой производительности (точнее, издержках TCP) идет речь при таких больших обьектах? MC>Ну а аргумент про NAT'ы совсем непонятен. В случае TCP наружу должен торчать только сервер, в случае UDP — оба конца. Где в случае UDP отсутствие проблемы с NAT'ами?
Система одноранговая (P2P) и в случае большого количества "соседей", а так же в силу их динамизма, создавать TCP подключения выходит накладнее чем использование UDP транспорта.
Проблема с TCP и NAT следующая: Я предполагаю открывать "окно" между 2мя узлами, находящимися за NAT'ом следующим образом. Допустим, текущий p2p оверлей состоит из 1го узла с паблик IP (A) и одного узла за NAT (B). К оверлею подключается новый узел (C), и ему необходимо соединиться с узлом (B). Используется помощь узла (А) — через него (B) и (С) обмениваются своими внешними адресами. Далее они начинают синхронно обмениваться пакетами по протоколу TCP. После того, как узел (В) пошлет пакет узлу (C), NAT узла (B) определенное время будет пропускать пакеты от узла (C) по этому адресу и можно будет установить соединение. Проблема с TCP в том, что как привязать 2 сокета на один адрес (слушающий сокет и сокет отправляющий сообщения для открытия "окна" узлу (C) ).
Здравствуйте, TarasCo, Вы писали:
TC>Здравствуйте, lostdnd, Вы писали:
L>>Но как быть, если объект разбивается на несколько пакетов при пересылке?
TC>UDP протокол не занимается фрагментацией ( в отличие от TCP, который пытается отсылать данные кусками не превыщающими MTU ). Датаграмма будет фрагментирована средствами IP протокола. И потом на приемном конце также дефрагметирована и передана клиенту уже в собранном виде. Таки образом, вызывая recvfrom в цикле Вы будете получать датаграммы полностью ( если буфера хватит ), в независимости от соотношения длины датаграммы и MTU. Невозможна ситуация получения кусков различных датаграмм. Кроме того, стоит помнить, что есть ограничение на максимальный размер датаграммы.
MC>В этом утверждении я не уверен. Тем более если речь идет про независимость от реализации NAT'а. Сильно сомневаюсь что все NAT'ы так делают.
Не все конечно, но большинство. Для "плохих" NAT'ов прийдеться использовать другие техники или сервера в качестве тунеля .
Здесь http://www.brynosaurus.com/pub/net/p2pnat/ есть небольшая статистика NAT'ов.
