Кто может объяснить, как устанавливается соединение в P2P сетях?
Вот, допустим, есть сервер и 4 клиента.
1-ый подключается к серверу, сообщает ему, что у него есть данные А.
3 других клиента подключаются к серверу, ищут данные А.
Как это будет выглядеть в свете недавно рассмотренного вопроса про подключение из-за фаервола?
Т.е. каждый клиент выходит в сеть из-за своего провайдера, и каждый знает адрес только сервера. Как сервер поможет установить прямое соединение клиентов?

Интересует не столько код, сколько принцип.

> Как сервер поможет установить прямое соединение клиентов?
да ни как. ИМХО.

> Интересует не столько код, сколько принцип.
насколько сам его понимаю, сервер дает клиентам только список других клиентов, а дальше они уже сами... между собой.
и если у пары клиентов один "с одной стороны" за натом, и "с другой" за другим натом, то никакого прямого соединения между ними не получится.
т.е. "закрытый" клиент инициирует соединение к открытому, вот и прямой канал. если оба закрыты, то только через промежуточный сервер (если там есть такие в торентах, у емула знаю есть).

> sniknik  (27.06.2012 00:24:01)  [1]

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

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

кстати у автора топика как раз вопрос, КАК, как имея внешний сервер, который получил эту пару внешних адресов от соединения, скормить их участникам и дальше (для обмена данными) оставаться в стороне...
???
я вот тоже не понимаю принцип.
с работой через сервер легко, а вот без него, используя сервер чисто как "катализатор" нет.

> sniknik  (27.06.2012 08:07:03)  [3]

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

Сервер сам по себе не сообщит, тут программу сервера писать надо и протокол
обмена разрабатывать, но сервер знает адреса и порты обеих клиентов, за
скольки бы они натами не сидели.
Иначе бы работа P2P была не возможна.

Сервера вообще может не быть (DHT, PEX).

> sniknik ©   (27.06.12 08:07) [3]

Пиры с открытыми портами используются как посредники для тех, кто за натом.

> Омлет  (27.06.2012 08:36:05)  [5]

Без сервера в этом случае не полноценная работа, получать сможет, а отдавать
после перезапуска нет.

Как я понимаю, вариант с сервером-посредником проще?(есть заранее известное "место встречи")

Как я еще понял из http://ilya-314.livejournal.com/109737.html P2P соединения идут по UDP?
И у клиента получаются пары соединений с каждым другим клиентом, с которым он обменивается?

> Anatoly Podgoretsky ©   (27.06.12 08:52) [7]
> Без сервера в этом случае не полноценная работа, получать сможет, а отдавать после перезапуска нет.

После перезапуска чего?

> получать сможет, а отдавать
> после перезапуска нет.

И получать не сможет, ибо его та м никто не ждёт.

> После перезапуска чего?

Клиента, естественно.
Принцип соединения то очень простой. Хоть за тремя огнестенами сиди, но если пакет вышел наружу по адресу А1 на порт П1, то "проход" этот будет открыт какое-то время. Огнестена будет ждать ответа с того же адреса на тот же порт.
Клиент к1 за стеной связывается с сервером с1, тот запоминает его адрес. То же делает и второй клиент к2. Теперь сервер знает адреса двух клиентов. Он начинает слать им пакеты, содержащие адреса друг друга (ответ сервера огнестена пропустит). Клиент к1, получив адрес к2 начинает слать ему пакеты, которые открывают для клиента к2 "проход" в огнестене.
к2 делает то-же самое, тем самым открывая "проход" в своей стене для пакетов от к1. В итоге каждый клиент в конце концов получит пакет от другого якобы в ответ на свой запрос. После этого связь установлена и оба клиента отправляют сигнал об установке связи серверу. Сервер, получив подтверждение о связи между к1 и к2 прекращает слать им пакеты с адресами. Всё. Далее возможны кучи вариантов. Открытые клиенты (без огнестены) могут так же работать серверами установки связи (как в Skype)
, список таких "серверов" может храниться на главном сервере, чтобы снизить на него нагрузку.

> Труп Васи Доброго ©   (27.06.12 13:45) [11]

Спасибо за наглядность.

> Клиент к1, получив адрес к2 начинает слать ему пакеты


При address restricted NAT на стороне клиента k2 пакеты от k1 упрутся в огнестену. И всё, облом-с.

Равно как и при port restricted NAT запросто может ждать облом, если NAT на стороне клиента-отправителя k1 по каким-либо причинам не может использовать порт отправителя, сообщенный ему сервером c1

> При address restricted NAT на стороне клиента k2 пакеты от
> k1 упрутся в огнестену.

Почему облом-то? Address restricted NAT будет отбивать пакеты от к1, поскольку к2 ему ничего не посылал. НО, ведь к2 получив от с1 адрес к1 тоже начинает слать в сторону к1 пакеты. Вот и получится что посте отправки пакета к2 -> к1 огнестена начнёт пропускать пакеты от к1, поскольку станет считать и ответом на исходящий запрос. Я же и писал что это "якобы" ответ, на самом деле получится что "ответные" пакеты начнут приходить раньше запроса, вот и всё. Сначала будут отбиваться, а потом канал установится.


> Равно как и при port restricted NAT запросто может ждать
> облом, если NAT на стороне клиента-отправителя k1 по каким-
> либо причинам не может использовать порт отправителя, сообщенный
> ему сервером c1

Ну предусмотреть для такого случая в своём протоколе команду "смени порт, сука" тебе конечно-же Кришна запретит.

> ведь к2 получив от с1 адрес к1 тоже начинает слать в сторону
> к1 пакеты


А k1 тоже за address restricted NAT...


> смени порт


Как ты прикажешь, к примеру, коническому NATу сменить порт ?)

> А k1 тоже за address restricted NAT...

И что это меняет? Схема та же самая. Клиенты не знают друг-друга, но они могут узнать через сервер, после этого они установят связь сами. Не веришь что получится - посмотри на Skype.

> Как ты прикажешь, к примеру, коническому NATу сменить порт
> ?)

При чём тут NAT? Это команда админу NATа :)

> что это меняет?


Это делает невозможным прямое p2p-соединение между клиентами, каждый из которых находится за address restricted NAT.


> Это команда админу NATа


Причем здесь админ ?
Тот же Скайп не дает никаких команд никаким админам. И стенку из address restricted NAT'ов он тоже не пробивает - просто Скайп-узел всегда имеет в резерве пару-тройку десятков альтернативных каналов, где нет проблемы двусторонних NAT-ограничений. Кроме того Скайп при возможности настраивает нужные правила в локальном брандмауере и доступном ему UPnP-сервисе.