eurekafag
08.11.2011 20:27 WOK
А вот как можно устроить бессерверный чятик по UDP, если с обеих сторон злобный NAT. Договариваемся о портах, пусть это будет 9000 со стороны A и 10000 со стороны B, можно и одинаковые брать. Сообщаем друг другу внешние IP (можно через DynDNS автоматизировать эту часть). Запускаем со стороны A: nc -u IP_B 10000 -p 9000
Со стороны B: nc -u IP_A 9000 -p 10000
Всё, как только каждый отправит хотя бы одно сообщение, «связь» установится. Если неткат ругается на флаги, проверьте, чтобы стоял и был выбран в альтернативах netcat-traditional, для netcat-openbsd флаги отличаются.
7 comments
recommend
bookmark
subscribe
google://udp+hole+punching
На самом деле, меня удивила работа OpenVPN по этому принципу (из статьи http://habrahabr.ru/blogs/network_techno... ). Я почему-то всю жизнь был уверен, что NAT меняет не только адрес, но и локальный порт на какой-нибудь из своих, поэтому, вроде как, угадать порт получателя с другой стороны не получится. И, в принципе, наверно, так оно и будет, если два клиента за натом попытаются работать с одним локальным портом и одним и тем же удалённым адресом и портом.
одно tcp соединение идентифицируется двумя IP адресами, и *двумя* портами.
Я и говорю, что если два клиента ЗА натом выставят одинаковый локальный порт и попытаются соединиться с одним и тем же удалённым сервером, один из них на нате должен соснуть.
Собсно: http://en.wikipedia.org/wiki/Network_add...
However, if two internal hosts attempt to communicate with the same external host using the same port number, the external port number used by the second host will be chosen at random.
Оказывается, такая связка локального и внешнего портов действительно опциональна, но работает. Раньше не приходилось задумываться о локальном открываемом порту, я всегда справедливо считал его рандомным и не стоящем внимания, поэтому и трансляция такого порта не интересовала. А тут вон какая польза, оказывается.
А STUN на что?
too old.