252 Кб, 1240x641меня интересует вопрос того, как пиры в торренте подключаются друг к другу? все их IP же серые и поэтому они не могут напрямую подключатся друг к другу. если же это происходит через посредника, то какой вообще смысл в пирах, если это все может делать централизованный сервер, если не учитывать вероятность его блокировки.
>>155
ну я знаю, что трекеры это те же самые обычные сервера, а что насчет обычных пользователей с раздечей?
ну я знаю, что трекеры это те же самые обычные сервера, а что насчет обычных пользователей с раздечей?
>>165
а. ну лан
а. ну лан
>>165
я просто хотел сделать децентрализованную сеть, типа торрента, где будет явное разделение ролей: будут узлы хранящие данные, а будут узлы, которые будут распространять между собой пакеты с запросами
я просто хотел сделать децентрализованную сеть, типа торрента, где будет явное разделение ролей: будут узлы хранящие данные, а будут узлы, которые будут распространять между собой пакеты с запросами
>>152 (OP)
Сначала изучи, как компьютер, не имея ничего, кроме случайного адреса из диапазона локальной сети, вообще связывается с произвольным устройством с публичным адресом в интернете, потом поймёшь, как могут (или не могут) это сделать два таких компьютера из разных сетей.
Теоретически всё просто: IPv4 предполагал, что всем устройствам, входящим в Интернет, будут выданы уникальные адреса, а локальные сети — это локальные сети, они сбоку. В те времена это было логично: на всё предприятие один сервер почты, он несколько раз в день как-то общается с внешним миром, что вам ещё нужно-то? На практике оказалось удобнее, быстрее и дешевле использовать NAT, он же файвол, он же маршрутизатор, там, где теоретически должна была начинаться подсеть организации, и пользоваться всего одним или несколькими IP-адресами вместо неё.
IPv6 предполагает, что всем устройствам выданы уникальные адреса, и это происходит, только сеть IPv6 не всем устройствам доступна.
Сначала изучи, как компьютер, не имея ничего, кроме случайного адреса из диапазона локальной сети, вообще связывается с произвольным устройством с публичным адресом в интернете, потом поймёшь, как могут (или не могут) это сделать два таких компьютера из разных сетей.
Теоретически всё просто: IPv4 предполагал, что всем устройствам, входящим в Интернет, будут выданы уникальные адреса, а локальные сети — это локальные сети, они сбоку. В те времена это было логично: на всё предприятие один сервер почты, он несколько раз в день как-то общается с внешним миром, что вам ещё нужно-то? На практике оказалось удобнее, быстрее и дешевле использовать NAT, он же файвол, он же маршрутизатор, там, где теоретически должна была начинаться подсеть организации, и пользоваться всего одним или несколькими IP-адресами вместо неё.
IPv6 предполагает, что всем устройствам выданы уникальные адреса, и это происходит, только сеть IPv6 не всем устройствам доступна.
>>152 (OP)
Если хочешь делать P2P приложение предполагая что все пиры серые - можешь закрывать проект сразу и ждать ipv6. Де факто тебе нужен хотя бы один пир к которому могут подключиться (трекер у торрентов) и от него узнать о других пирах.
А вот общение между двумя пирами происходит интереснее, тут надо указать как NAT работает когда ты подключаешься к какому-нибудь серверу:
1) В NAT-е есть табличка, которая указывает от какого локального IP и порта исходит подключение на какой IP и какой порт.
2) По этой табличке NAT, когда приходит соединение извне от конкретного IP и порта перенаправляет трафик
3) Спустя N времени и/или по другим условиям запись в таблице стирается
А теперь собственно фокус подключения двух серых пиров, так называемый Hole punching:
1) Пир А соеденяется с белым пиром, узнает список пиров в сети.
2) Через белого пира отправляет сообщение пиру B о том, что хочет подключиться, а также свой серый IP и порт.
3) Пир B подтверждает что согласен на подключение, и отправляет также через сервер ответ пиру А, заодно с IP и портом подключения.
4) Пир А, получив ответ замеряет время которое прошло с момента отправки сообщения в пункте 2 до получения ответа
5) Пир А отправляет пиру Б через сервер сообщение типа "Давай пытайся подключиться к моему IP"
6) Через половину времени вычисленного в пункте 4, пир А создает отправляет подключение напрямую к пиру Б, создавая в своем NAT-е запись типа от меня к пиру B.
7) Пир Б тем временем, получив сообщение СРАЗУ отправляет подключение к пиру А напрямую, создавая аналогичную запись в своем NAT-е
К тому моменту как сигналы доходят до тех к кому должны дойти, в соответствующих NAT-ах стоят записи о том, что сообщения с этого IP надо перенаправит на такой-то адресс и поэтому сигнал проходит. Happy end, пиры подключены напрямую, сервер больше (пока) не нужен.
В описании опущено пару подробностей, например NAT-ы бывают разными но в целом все так.
Если хочешь делать P2P приложение предполагая что все пиры серые - можешь закрывать проект сразу и ждать ipv6. Де факто тебе нужен хотя бы один пир к которому могут подключиться (трекер у торрентов) и от него узнать о других пирах.
А вот общение между двумя пирами происходит интереснее, тут надо указать как NAT работает когда ты подключаешься к какому-нибудь серверу:
1) В NAT-е есть табличка, которая указывает от какого локального IP и порта исходит подключение на какой IP и какой порт.
2) По этой табличке NAT, когда приходит соединение извне от конкретного IP и порта перенаправляет трафик
3) Спустя N времени и/или по другим условиям запись в таблице стирается
А теперь собственно фокус подключения двух серых пиров, так называемый Hole punching:
1) Пир А соеденяется с белым пиром, узнает список пиров в сети.
2) Через белого пира отправляет сообщение пиру B о том, что хочет подключиться, а также свой серый IP и порт.
3) Пир B подтверждает что согласен на подключение, и отправляет также через сервер ответ пиру А, заодно с IP и портом подключения.
4) Пир А, получив ответ замеряет время которое прошло с момента отправки сообщения в пункте 2 до получения ответа
5) Пир А отправляет пиру Б через сервер сообщение типа "Давай пытайся подключиться к моему IP"
6) Через половину времени вычисленного в пункте 4, пир А создает отправляет подключение напрямую к пиру Б, создавая в своем NAT-е запись типа от меня к пиру B.
7) Пир Б тем временем, получив сообщение СРАЗУ отправляет подключение к пиру А напрямую, создавая аналогичную запись в своем NAT-е
К тому моменту как сигналы доходят до тех к кому должны дойти, в соответствующих NAT-ах стоят записи о том, что сообщения с этого IP надо перенаправит на такой-то адресс и поэтому сигнал проходит. Happy end, пиры подключены напрямую, сервер больше (пока) не нужен.
В описании опущено пару подробностей, например NAT-ы бывают разными но в целом все так.
>>492
спасибо за инфу
спасибо за инфу
>>247
так можно использовать пакеты широкого вещания
так можно использовать пакеты широкого вещания