Доброго времени суток, господа! Вопрос конечно не касается программирования непосредственно, но, я не смог найти места в интернете, где бы, на мой взгляд, можно было бы задать этот вопрос. Я конечно же представляю, что такое udp и чем он отличается от tcp и т.д и т.п, но! Встала задача реализовать передачу данных между клиентами по УДП протоколу, через промежуточный публичный сервер. Конечно же проблема кроется в том, что клиенты могут не иметь реальных ИП.. С тсп, ессесно, это достигается за счет принятия подключения (и кстати, в таком случаи интересно узнать, как такие сокеты отправляют данные, но наверно нужно глубоко копать спецификацию сетей или что нибудь подобное, поэтому если кто-то попытается ответить между делом, с удовольствием прочитаю) Но как же быть с удп? Я уже было отчаялся, но потом подумал, что наверно проблема должна иметь скрытое решение) к тому же, вроде бы и удп прокси существуют... Собственно, ребята, нужно как-то решить задачу. З.Ы: Хочу Использовать УДП для передачи больших объемов мультимедийных данных, т.к он шустрее ТСП..
Наверное тут нужно уточнить, как это - "не имеют реальных ip"? Как же тогда ip пакет формировать? ведь udp надстройка над протоколом ip, а а нем (в протоколе ip) обязательны поля - "IP-адрес отправителя (32 бита)" и "IP-адрес получателя (32 бита)" ?? )))
Хм. Возможно, я не совсем корректно выражусь, но под нереальными ИП я имел ввиду ситуацию, что большенство провайдеров раздают интернет клиентам таким образом, что подключиться к ним нельзя, т.к ип адрес, не является настоящим(видимым, белым, других синонимов не встречал)
ну так и послать провайдеру пакет с ip dst клиента. Если пров сумасшедший и настроил переадресацию всего и вся, пропустит. Или мож админ свихнулся и upnp включил - тоже вариант. имхо, только для домашней сетки можно сделать с некоторыми условностями. у провайдеров злые админы все заблочат на корню.
Хорошо, а почему же все таки при приеми соединия по тсп, сокет потом может читать и отправлять данные, даже в случае серого ип.. (если короче - хттп же работает всегда)
потому что сначала клиент шлет пакет с флагом на установку соединения. если циска провайдера умная, она это дело просекает и ждет ответа некоторое время от сервера с флагом подтверждения установки соединения. если пришло, она пакет пересылает клиенту, далее идет обмен данными, в конце пакет с разрывом соединения.
>не является настоящим(видимым, белым, других синонимов не встречал) Это NAT называется Почитайте про NAT, что он с пакетами делает, станет понятнее. Можете например разобраться на примера DNS, как от него в NAT возвращаются UDP-пакеты и почему.
Luzer, а что мешает различать подключенных абонентов по комбинации source ip-address/source port? Если несколько разных абонентов будут подключаться через один и тот же роутер с динамическим NAT, наружу они выйдут конечно же с одним и тем же IP-адресом, но с разными source портами. Правильный динамический NAT осуществит подмену не только source-адреса, но и source-портов так, чтобы с наружней стороны они обязательно отличались.
Не наступите на грабли! TCP обладает авторегуляцией скорости отправки за счет наличия очень ограниченного окна передачи. Без такой авторегуляции в узких горлах (там, где за более широким каналом идет более узкий) у вас неограниченно начнут расти очереди, и когда дойдут до предела - пакеты просто начнут пропадать в большом количестве. Если же вы попытаетесь сами реализовать авторегуляцию отправки - то вы в том или ином виде фактически на UDP реализуете окно передачи TCP как раз со всеми теми недостатками, от которых хотите избавиться. UDP можно использовать только там, где передачи либо короткие, либо имеют постоянную по времени и существенно ограниченную скорость отправки, типа IP-телефонии.
_sheva740 Ну задача может быть и не сверх задача) но определенно пока не понятна в плане решения. Собственно да, хочу сделать именно то, что написал, а про прокси я упомянул, как о возможном решении проблемы с невозможностью достучаться до подобных клиентов. Dmitry_Milk Спасибо за справку, да, именно для IP-телефонии буду использовать удп. З.Ы: Нубское уточнение: Ведь по сути дела когда тсп принимает подключение в созданном сокете методом accept уже где-то прячится информация о том, как достучаться до удаленного клиента, следовательно ничего не должно мешать в обычных датаграммах использовать ту же информацию, верно ?) З.Ы.Ы: Ушел читать про NAT
Действительно, если делать ответ на только что полученное сообщение, когда извлекается обратный адрес и порт, можно достучаться через "недостучаемое". но, увы, в моем случае, порт сменяется примерно через 80 секунд, если отсутствует активность... Стало быть вопрос следующий, возможно как-то определить этот период какими нибудь служебными запросами, не знаю... или может быть изменить его. Тогда проблему можно считать решенной хоть и с натяжекой...
Пусть клиент периодически стучит серверу, скажем, с периодом в полминуты, эдакий keepalive: - сервер, я еще жив! - ага, клиент, слышу тебя... ...30 сек... - сервер, я еще жив! - ага, клиент, слышу тебя... и т. д.
да да да, именно такое решение и хочу использовать, но для большей эффективности хочется эти самые 30сек определить. мб это возможно. Я так понимаю, это NAT где-то ведет учет сопоставления портов...
Именно так. Кстати, мне, как человеку, натрахавшемуся с IP-телефонией на некачественных каналах, давно хочется, чтоб IP-телефония стала чуть-чуть умней, различая, когда в человеческой речи допустима пауза/разрыв, и за счет этого слала небольшие, но самодостаточные порции кодированного потока, которые на приемной стороне воспроизводились бы только после получения такой самодостаточной порции целиком. Тогда можно было бы отказаться от всей этой канители H245 H323, и работать одним лишь TCP-соединением. Лучше пусть задержка в секунду-две, чем без задержки, но кваканье.
Dmitry_Milk Сомневаюсь, что я стану именно тем, кто сделает IP-телефонию чуть-чуть умнее ковырялся, ковырялся и все что удалось найти это некий протокол STUN, который позволяет определить тип НАТ, но увы, вроде как это все, для чего он предназначен... Еще есть язык UPnP для маршрутизаторов, но думаю, это не того коллектива песня В том смысле, что заморачиваться не стоит, хотя в редких случаях, она (песня эта) пожалуй сможет помочь... если конечно я ее правильно понял... Эх... Никто не говорил, что будет легко ... Жду, может быть, каких нибудь комментариев, в связи с появлением в теме новых слов
Дык, а какая проблема-то осталась? вроде ж на все вопросы Вы нашли ответы? Абонентов различать по паре адрес/порт, а чтоб запись о временной трансляции не исчезала из таблиц NAT-роутеров по таймауту - слать кипэлайв. Попутно от этого кипэлайва получить другие профиты, типа обнаружения внезапного отключения абонента без соблюдения протокола. Полминуты самый нормальный кипэлайв будет, обычно таймаут меньше минуты не бывает, для надежности можно слать серию пакетиков. Все будет работать одинаково независимо от того, работает абонент через НАТ или напрямую от белого адреса, зачем вам копаться с NAT роутерами?
Дык вроде и нашел, но с таймаутом все таки Вы не совсем правы) 30 секунд может не хватить(например, сейчас проверил на виртуалке, там сопоставление живет ровно 30 секунд) Но и как на это повлиять я тоже не знаю. В довесок, как уже отмечалось ранее в интересном диалоге между клиентом и сервером, придется слать пакеты "жизни" и ожидаеть его подтверждения, в противном случаи, через какой-то еще меньший период дублировать пакет "жизни" и так n-раз... Соответственно должен быть какой-то запас времени(который нужно бы как-то узнать все таки) Хотя, опять таки, ждать подтверждени как, в теперь уже известном, диалоге не нужно, главное ведь, чтобы НАТ продолжал удерживать порт, а он вроде как должен это делать вне зависимости от того, есть ли жизнь за ним самим... Вообще, только из-за этого придется ввести пакеты(некий протокол) в обмен данными между клиентом и сервером(промежуточное звено между другим клиентом), а так конечно хотелось отдавать ровно то, что пришло с одного конца на другой конец) эх..
Теоретически таймауты для трансляций NAT задаются админами роутеров. Хотя чаще всего админы их не трогают и оставляют то, что задано по умолчанию. Скажем, в Cisco-роутерах возможно произвольно задать разные таймауты для ICMP, TCP, UDP или других трансляций, а так же в зависимости от некоторых флагов, типа SYN, FIN. Каких-то стандартных требований к NAT-таймаутам нет, выставляются они исходя из критериев разумности, и если админ выставит очень нехорошие таймауты - на него же в первую очередь все шишки и повалятся. Слишком маленькие - юзеры будут жаловаться на нестабильную работу, слишком большие - роутер может загнуться от раздувания таблиц, особенно если нет аппаратной поддержки NAT. Не факт. NAT может оказаться умным, особенно на роутерах с файрволами/антиатакерами, поддерживая большой таймаут только на те трансляции, для которых также приходят ответы извне. Иначе безответные трансляции вполне можно трактовать как попытку перебора/сканирования и грохать почти сразу же.
Для передачи мультимедийного контента есть протокол SCTP, он быстрее TCP, с некоторыми запилами можно пускать через NAT. http://tools.ietf.org/agenda/70/slides/behave-5.pdf Чтобы идентифицировать клиента за натом к шапке сообшения можно добавить ид. Если вдруг изменится адрес порта или у клиентов из одной сети будет одинаковый порт можно будет узнать от кого пришло сообшение. Пример реализации так называемого NAT Punchthrough есть тут http://www.raknet.net/raknet/manual/natpunchthrough.html
