Интересно существует ли в интернете какая ни будь возможность соединить два компа (на прямую) с динамическими IP, не используя сервера-посредника? 
Может есть какие ни будь для этого универсальные ресурсы в интернете, позволяющие как то временно зафиксировать временные адреса как постоянные (не зависимо от провайдера)?


Это сообщение отредактировал(а) SVN74 - 18.3.2009, 00:23

DynDNS

Да, хорошая штучка, но с NAT такой номер не пройдет...
Конечно, по любому придется  использовать сервер- посредник, но для большого количества клиентов и с большим объемом данных этот вариант не очень хорош, - причина линия интернета на сервере просто не сможет пропускать через себя большие объемы информации, причем надо без задержек. И тут постает вопрос, возможно ли обдурить (клиентскую) сторону создав первоначально соединение с динамических адресов двух клиентов с сервером на статике, а затем сервер соединит их сокеты и распрощается с ними, затем клиенты смогут работать между собой вне сервера.
Конечно, это с области фантастики, но как известно нет ничего невозможного.
Может кто ни будь слышал о таких извращениях?

Наверно P2P - торрент сети именно так и дeлают, по моему?

Это сообщение отредактировал(а) Олег2005 - 30.3.2009, 21:44

Да, Р2Р примерно так и работает, но в большей части по статических адресах, а динамические все равно через соседние сервера.
Интересно , как известно при создании сокета между клиентом и сервером, - сервер получает инфу о клиенте в виде IP и Порта (обратного), возможно ли “законектить”  на стороне (динамического) клиента его сервер(с таким же номером порта)  по полученному от клиента порту?

Обычно говорится, что порт однозначно определяет приложение (одно) 
Но есть опция SO_REUSEPORT. Мож ее каким-то боком можно?
Не могу точно сказать  

Это сообщение отредактировал(а) Олег2005 - 30.3.2009, 21:48

Если брандмауэр, который обеспечивает NAT для динамических клиентов, умеет трассировать соединения по протоколам типа FTP. то можно попробовать замаскироваться под этот протокол и передать данные для второго соедиения. Тогда брандмауер пробросит внешний порт на внутренний, и второй динамический клиент сможет присоединится к первому. Ну а если есть возможность написать и подключить к брандмауэру свой модуль трассировки, то и маскироваться не надо.

То бишь если я правильно понял обратный порт от клиента - это и есть пропущенный порт через firewall NAT(а) и возможно подконектиться к ждущему серверу(на стороне динамического клиента) по данному порту, главное не разрывать соединение с главным сервером ???

Вроде да. Но это только идея. На практике я такого не делал и не видел. 
вот выдержка из документации по iptables


Кроме ftp есть и другие протоколы для которых необходимо обратное соединение. 

Вот провел эксперимент: На внешнем IP запустил сервер, далее с посторонней сети (имеющей внутренний IP с центральным шлюзом NAT) запустил клиента на "коннект TCP" к указанному адресу, - установилась связь без проблем и внешний IP получил обратный IP и ПОРТ клиента(соединение не разрываю), далее хочу «законнектить»  клиента со стороны сервера по указанному (обратному) ПОРТУ клиента, для чего сначала пытаюсь запустить сервер на стороне клиента (внутреннем адресе) и вот тут та сервер и  выдает сообщение (обычно разрешается запускать только один сервер по указанному порту), ну оно и понятно, ведь порт уже занять клиентом...
==========
Как можно было бы все таки запустить (принудительно) сервер по указанному порту (на стороне клиента)?
Таким способом на мой взгляд любой другой хост(с внутренним IP) может «законнектиться»  к другому хосту(с внутренним IP) , зная его обратный порт и адрес (действующего соединения с центральным сервером), то бишь у внутреннего хоста  появляются ворота во внешний мир (по определенному порту).
==========
я прав???   
========== 
кстати UDP и TCP сервера свободно работают по одному порту, буду пробовать подсесть на TCP с помощью UDP... 


Это сообщение отредактировал(а) SVN74 - 9.4.2009, 22:40

даю маячек
для соединения двух сокетов слушающий сокет совершенно необязателен - можо соединить два акивных сокета если они знают адреса друг друга

не получится
сокет иденифицируется связкой протокол+адрес+порт

SVN74, у меня следующая мысль,
если послать UDP пакет с внутреннего IP на белый IP, то в NAT какое-то время будет запись о том, что мы обращаемся к белому IP, это нужно для  того чтобы можно было в ответ (внутреннему IP) пысылать какие-либо данные, которые уже будут пробрасываться с NAT на внутренний IP.
Иначе не организовать взаимодействие через NAT.

Так вот, есть задумка, что если на обратный порт и IP (который пришел в UDP пакете), послать ответный покет с любого другог IP, то он будет принят. Но это лишь мои догадки.

Вы провели подобный опыт, но как я понял на TCP/IP, попробуйте тоже самое, но на UDP.

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