Надежный UDP

Не совсем понятна мотивация, если необходимо обеспечить высокоскоростную гарантированную доставку в заведомо надежной сетевой среде, на это есть патчи ТСР, как пример, вот это: http://www.stanford.edu/~alizade/Site/DCTCP.html

Ну и еще пару ссылок: http://udt.sourceforge.net/doc/udt-design-sc04-v8.pdf http://www.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf

Интересная подборка по ultra-low latency messaging: http://www.250bpm.com/

Еще есть направление - оптимизация стандартного ТСР протокола в надежной среде для очень серьезного снижения его латентности, попадалось HOWTO от 29West, вроде как на их сайте есть, это одни из ведущих в части ультранизколатентного networking.

Мотивация проходить NAT. Для TCP реализованы унылые зачатки. Для UDP - куча избитых алгоритмов

Из того что как то попадалось - вот это: http://linide.sourceforge.net/nat-traverse/

Сам с этим не работал, будет интересно Ваше мнение

Я не знаю насколько это для Java... Но NatTrav для Java, правда оно GPL, значит немного напряжно

В libjingle есть реализация «pseudo TCP», которая очень легко портируется, т.к. абсолютно не привязана к остальному коду. Можно вытащить ее оттуда как есть и использовать через JNI. Или поискать готовые привязки libjingle или libnice (там тот же код используется для TCP-over-UDP) для Java.

Болезненно, но вариант. JNI не подходит, ибо Pure Java, но портировать на Java можно будет попробовать, когда будет время

В libjingle есть реализация «pseudo TCP», которая очень легко портируется

А вы как-то с этим работали?

> портировать на Java можно будет попробовать, когда будет время

Там реально работы на полтора дня. Один класс, pure ANSI C++, никакие системные вызовы, включая работу с сокетами, не используются - все через колбеки.

> А вы как-то с этим работали?

Да, выдернул для одного своего проекта. Лицензия BSD-style.

И как произвоидительность под нагрузкой по сравнению с TCP? А какая у вас была причина юзать UDP?

Для TCP реализованы унылые зачатки. Для UDP - куча избитых алгоритмов

Можно поподробнее? Ты имеешь в виду hole punching?

STUN, ICE

> И как произвоидительность под нагрузкой по сравнению с TCP?

Судя по коду, проблем с производительностью быть не должно. В моем случае канал с TCP-over-UDP использовался только там, где была важна надежность, а не скорость доставки, поэтому специально ничего не замерял.

А какая у вас была причина юзать UDP?

Такая же, как у тебя :)

Такая же, как у тебя :)

О, ништяк, значит работает задумка. Наверное через STUN? Тоже сделаю такое, правда уж такие выверты как pseudo tcp в Java тяжело найти. Ну уж этот компонент если портирую, то выложу в опенсорц под Apache License

> О, ништяк, значит работает задумка.

Конечно, работает. В частности, разработчики libnice (реализация ICE под GLib) тот же код позаимствовали.

Наверное через STUN?

STUN или TURN, в зависимости от обстоятельств. Я не знаю, как сделано в NatTrav, но во всех реализациях ICE, которые я видел, всегда использовалась некая абстракция сокета, т.е. в клиентском коде не всегда известно, как именно доставляются данные.

STUN или TURN, в зависимости от обстоятельств.

Простите что отвлекаю, но раз у вас есть опыт работы с этим... В каком случае у вас переход на TURN? Почему STUN не достаточно?

У них там еще лицензия такая, надо с этим вопросом разобраться если опенсорсить. Нельзя упоминать автора, вообще мутный вопрос. Если портирую, то нужны ссылки на libjingle и Google?

> В каком случае у вас переход на TURN? Почему STUN не достаточно?

Hole-punching, применяемый в STUN не сработает, если один из пиров находится за симметричным NAT'ом (встречается, к сожалению). В этом случае нужен какой-нибудь relay-сервер, в частности TURN.

> Если портирую, то нужны ссылки на libjingle и Google?

Да, нужно повторить их копирайт, условия и дисклеймер где-нибудь в документации к программе.

Меня сбило с толку

The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission.

Это означает, что, грубо говоря, ты не можешь написать «Google одобряет» про свою программу, будь то реклама или документация, только потому что ты использовал их код.

Ок, понятно

Еще один вопрос, если не тяжело. Вы просто используете STUN и TURN. Я так понял что ICE - это какое-то более комплексное и совершенное решение. Есть смысл использовать? Или STUN подойдет?

ICE - это только название соответствующего RFC и описываемой в нем техники «обхода» NAT, которая опирается на STUN и TURN. Т.е. есть отдельные RFC и для STUN, и для TURN, а ICE описывает, как использовать их в комплексе: сбор адресов-кандидатов и прочее. Собственно, алгоритм выбора «STUN или TURN» описан как раз там. Смысла детально вникать во все это нет, т.к. наверняка и для Java должна быть полная реализация ICE, а не только STUN (может NetTrav - это оно и есть, я не в курсе)

На джаве нет, но на Си есть enet

http://enet.bespin.org/

Именно что гарантия доставки + порядок для udp

Либа живая, проверенная и ее используют некоторые игрушки.

Есть IcedJava. Там немного с документацие туговато, но вообще можно поковырять

> Есть IcedJava. Там немного с документацие туговато, но вообще можно поковырять

Ты смотри по возможностям. TURN потребует от тебя наличия сервера с прямым IP, через который будет гоняться трафик для особо запущенных клиентов (тех, что за симметричным NAT'ом). Я использовал p2p в двух своих проектах, причем в одном из них, если требовался TURN, просто выводилось сообщение о невозможности установления соединения (т.е. было достаточно только реализации STUN), т.к. не всегда целесообразно, например, предоставлять для всех желающих relay-сервера бесплатно. Это уже зависит от специфики твоей программы. В скайпе, например, в качестве TURN-сервера выступает каждая супер-нода, т.е. и собственные сервера скайпа не используются и все счастливы.

В скайпе, например, в качестве TURN-сервера выступает каждая супер-нода, т.е. и собственные сервера скайпа не используются и все счастливы.

У меня есть возможность применить такое решение.

Встречал. В недрах всяких p2p прокси-туннелей для прозрачного пробоя NAT. Там как транспорт использовались обычно сторонние лицензированые реализации slingshot или RTP. (клиентские TCP сессии заворачивали в это и радовались) Была так же либа, реализующая UDT. Самопалами народ редко заморачивается.

UDP ненадёжный по определению.

>UDP ненадёжный по определению.

Ну что за бред? Всегда поверх udp можно нагородить протокол не менее надежный чем tcp

А в TCP один хер куча умников отключает алгоритм Нейгла, где-то прочитав ключевую фразу «потому что тормоза» или.... «для повышения параллелизма вычислений на клиенте и сервере» (с) http://www.rsdn.ru/forum/network/3475612.flat.aspx#3475612

> Ну что за бред? Всегда поверх udp можно нагородить протокол не менее надежный чем tcp

Бред у тебя. Автору темы необходимо полключиться к уже существующим сервисам, работающим через UDP без всяких костылей.

> Автору темы необходимо полключиться к уже существующим сервисам, работающим через UDP без всяких костылей.

Ты бы хоть в суть проблемы вник немного перед постингом.

>> Ну что за бред? Всегда поверх udp можно нагородить протокол не менее надежный чем tcp

Бред у тебя. Автору темы необходимо полключиться к уже существующим сервисам, работающим через UDP без всяких костылей.

Мне кажется, что если бы ты прочитал хоть одно сообщение ТС, то понял, что это не так.

Ненавистный micro transport protocol

> micro transport protocol

Ну зачем так сразу, есть еще поддержка SCTP, часто прямо в ведре.

RUDP

Её поддержку, кстати, обещают запилить в седьмой яве. Но кажись, только для соляры.

В Java не бывает «только для платформы Х» ))

Я правильно понимаю что сейчас самая распространнёная техника обхода NAT это hole punching(для выбора портов используется stun-сервис)?

А turn это тупо сервак с внешним ip который проксирует трафик клиентов через себя?

хорошую тему подняли - тоже вот начал вникать в эти технологии, пока в теории, но начинаю переходить к тестовым примерам