Перейти к содержимому
Калькуляторы

Осуществление p2p файлообмена для нескольких сетей через сервер

Собственно сабж.

Имеется три локальных сети с непересекающимися диапазонами адресов.

Имеется сервак, к которому все эти три локалки подключены.

Нужно каким то образом реализовать файлообмен между сетями через этот сервер, но не просто так, а несколько более хитрым образом.

То бишь если файл можно утянуть в своей локальной сети, то он должен стягиваться из неё, если файл есть у кого то из других двух сетей, то должен задействоваться серв и файл должен качаться через него.

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

В общем как бы такое реализовать? Говорю сразу, FTP не предлагать, ибо все три канала всего по 100 мбит, посему нужен именно p2p и использование серва допустимо только при отсутствии файла в своей локальой сети.

На ум ничего кроме написания собственного костыля пока не приходит.

Изменено пользователем Lampus

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если убрать такое жесткое ограничение на "использование серва допустимо только при отсутствии файла в своей локальой сети" обычный локальный DC p2p обмен вам полностью подойдёт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если убрать такое жесткое ограничение на "использование серва допустимо только при отсутствии файла в своей локальой сети" обычный локальный DC p2p обмен вам полностью подойдёт.
Да неужели?

P2P оно ж не просто так называется, а от англ. "Point to Point", то бишь между клиентами должно быть _прямое_ соединение.

Есть сеть А с диапазоном 10.0.0.0/8 и сеть Б с диапазоном 192.168.0.0/16.

Как человеку из сети А забрать файл с человека из сети Б?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если убрать такое жесткое ограничение на "использование серва допустимо только при отсутствии файла в своей локальой сети" обычный локальный DC p2p обмен вам полностью подойдёт.
Да неужели?

P2P оно ж не просто так называется, а от англ. "Point to Point", то бишь между клиентами должно быть _прямое_ соединение.

Прямое, да? А мужики-то и не знают: http://ru.wikipedia.org/wiki/P2p.

p2p означает только то, что между узлами нет посредника. К подсетям и маршрутизации это не имеет абсолютно никакого отношения.

Есть сеть А с диапазоном 10.0.0.0/8 и сеть Б с диапазоном 192.168.0.0/16.

Как человеку из сети А забрать файл с человека из сети Б?

Через роутер, разумеется. Других путей не может быть в принципе.

И даже более того - если человек А1 хочет забрать файл у человека из А2, то трафик всегда будет идти внутри сети. А если человек А1 хочет забрать файл у человека Б1, то трафик всегда будет идти через роутер. Других вариантов нет.

Поэтому вопрос на самом деле сводится к тому, как сделать так, чтоб при наличии в списке пиров людей А2, Б1, В1 для человека А1 использовался только А2.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поднять на сервере l2 openvpn, все клиенты коннектятся на ваш сервер, выдаёте ip адреса из сети, которая не входит ни в A, ни в Б, ни в C. Неудобство в том, что придётся всем ставить openvpn.

 

Далее, если использовать протокол bittorrent без DHT, то пишется патч на трекер, в котором смотрите, что если запрос пришёл из сети C(надо узнавать "настоящий" ip по ip, которому ему дал openvpn, в список пиров записывать и "настоящий" ip и впнный) и есть сид(ну или лучше 2-3 сида/пира) из сети C, то других пиров ему не отдаёте, а если нет пиров из сети C, то отдаёте всё подряд. При этом в торрент-файлах адрес трекера должен быть из vpn.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

p2p означает только то, что между узлами нет посредника. К подсетям и маршрутизации это не имеет абсолютно никакого отношения.
Под словом "прямое", я имел в виду лишь то, что пиры могут получать данные друг с друга свободно, речи о том что все пиры в пределах одного физического сегмента не было. С каждой стороны сети и без того с кучей роутеров.
Через роутер, разумеется. Других путей не может быть в принципе.
В данном случае роутер сделать нельзя, банальный маскарадинг тут не прокатит, по причине указанной выше. А другие пути есть.

 

Поднять на сервере l2 openvpn, все клиенты коннектятся на ваш сервер, выдаёте ip адреса из сети, которая не входит ни в A, ни в Б, ни в C. Неудобство в том, что придётся всем ставить openvpn.

 

Далее, если использовать протокол bittorrent без DHT, то пишется патч на трекер, в котором смотрите, что если запрос пришёл из сети C(надо узнавать "настоящий" ip по ip, которому ему дал openvpn, в список пиров записывать и "настоящий" ip и впнный) и есть сид(ну или лучше 2-3 сида/пира) из сети C, то других пиров ему не отдаёте, а если нет пиров из сети C, то отдаёте всё подряд. При этом в торрент-файлах адрес трекера должен быть из vpn.

Над тем, что бы пропатчить xbtt я уже думал, даже кой чего уже наковырял. Ну вот зачем здесь openvpn?

Можно же сделать проще - патчим трекер таким образом, что бы он в случае когда для юзверя из сети А не может найти локального пира, делал портмаппинг пира из сети Б на случайный порт сервера, а затем сервер выдаёт себя в качестве локального пира.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>Можно же сделать проще - патчим трекер таким образом, что бы он в случае когда для юзверя из сети А не может найти локального пира, делал портмаппинг пира из сети Б на случайный порт сервера, а затем сервер выдаёт себя в качестве локального пира.

 

Ну да, выглядет красивей. Только небольшое неудобство, что торрент-файлы надо генерить разные в зависимости от того, откуда клиент или как-то договориваться о том, чтобы днс-сервера, которые используются клиентами А, Б и С отдавали нужный IP.

 

По поводу костылявости, чтобы это не выглядело как костыль, нужно, чтобы владельцы сетей A,B и C договорились о нормальном пиринге, тем более, если Вы говорите, что адреса не пересекаются. Сейчас же это выглядет так - у Вас в доме 3 провайдера, вы подключились ко всем трёт и пытаетесь их как-нибудь скрестить.

Вы уверены, что нужен именно xbt? Патчить его не очень приятно, потому что там ни одного комментария на весь код, в принципе можно сделать что-то не очень сложное, но вот понять его "глобальную" логику работы трудновато. Может быть какой-нибудь аннонсер на php+sql, который будет проще "пропатчить"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Через роутер, разумеется. Других путей не может быть в принципе.
В данном случае роутер сделать нельзя, банальный маскарадинг тут не прокатит, по причине указанной выше. А другие пути есть.

Что в таком случае означает фраза "должен задействоваться серв и файл должен качаться через него"? Что один кладёт на сервер, а другой забирает? Почему нельзя сделать роутер из этой же машины, раз уж все к ней подключены? Зачем маскарадинг, если разные адресные пространства у всех?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если убрать такое жесткое ограничение на "использование серва допустимо только при отсутствии файла в своей локальой сети" обычный локальный DC p2p обмен вам полностью подойдёт.
Да неужели?

P2P оно ж не просто так называется, а от англ. "Point to Point", то бишь между клиентами должно быть _прямое_ соединение.

Есть сеть А с диапазоном 10.0.0.0/8 и сеть Б с диапазоном 192.168.0.0/16.

Как человеку из сети А забрать файл с человека из сети Б?

нда.....

как как - чтобы А забрал из Б - маршрутизация - помоему очевидно! - а трекер в центре!

 

но вам это почему то не подходит - почему не признаётесь!

а костыли воротить - подходит :)))

Изменено пользователем Lynx10

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>Почему нельзя сделать роутер из этой же машины, раз уж все к ней подключены?

Для этого машина должна быть либо шлюзом по умолчанию для клиентов сетей А,Б,С, либо иметь возможность аннонсировать сети по дин. протокол. маршрутизации, либо должны быть специфичные статические маршруты на неё со стороны ближайшего маршрутизатора из этих сетей. Если сети А,Б и С являются едиными L2-доменами(но шлюз у них не сервер о котором идёт речь), тогда статические маршруты можно прописать на клиентах и заниматься роутингом на сервере. Вроде как очевидные вещи говорю.

 

Исходя из описания темы, сервер является обычным хостом, просто подключен к трём сетям(при этом сети А,Б,С как я понимаю побиты на подсетки и в каждой свой шлюз)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Исходя из описания темы, сервер является обычным хостом, просто подключен к трём сетям(при этом сети А,Б,С как я понимаю побиты на подсетки и в каждой свой шлюз)

Маршруты на подсети выдаются по DHCP безо всяких сложностей. А если у клиентов весь трафик ходит через шлюзы, т.е. и на указанную машинку они смотрят через них, то проблемы вообще никакой - потратить день на настройку маршрутизации и всё. Но мне кажется, что ТС имел в виду что-то другое, поэтому хотелось бы услышать ответы на вопросы именно от него.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ближе всех к истине находится товарищ s.lobanov =)

Всё с начала и по порядку.

У нас в городе грёбаная туча провайдеров (всего то 25 разных контор). Большая часть из них имеет локальные сети. Причём каждый пров стремиться держать свой набор локальных ресурсов. Но трабла в том что набор везде одинаков (торренты, игровые сервера ну и прочее в том же духе). Кому чего не хватает на оф. ресурсах начинает городить т.н. "пользовательский локальный ресурс". Ситуация банальная и думаю все с ней знакомы. Маразм настолько велик, что для того что б скачать фотки у товарища с соседнего дома, подключенного к другому прову, приходится использовать внешний канал и гонять весь трафик через M-IX. При этом провайдеры упорно не хотят пиринговаться. Но это не слишком удивляет, ибо бюрократия в конторах ещё та. Например, в одной из контор, чей головной офис в москве, что бы на сервере тупо порт для игрушки открыть, нужно писать служебную записку. Другая контора является монополистом в сфере подключения пользователей по ADSL, а FTTx подключениями занлась совсем недавно, поэтому бюрократия в ней тоже процветает. Мы пытались писать письма, мол сделайте пиринг, но нас хрен кто слушает.

А теперь к технической части проблемы.

Есть машинка, банально подключеная к трём провам (скоро уже к 4-м =) ). Каждый канал 100 мбит, то бишь весьма скромно, ресурсы машинки опять таки ограничены тем кол-вом средств которые я могу на неё потратить, рулить маршрутизацией в сетях я не могу, а могу только ковыряться в своей песочнице (на своём сервачке). Так что нужно такое решение для файлообмена, чтобы мой сервачёк задействовался в качестве посредника, только в том случае, когда файл нельзя найти в своей сети (а бывает это не шибко часто, ибо контент тех же трекеров дублируется у всех провов процентов на 80%).

Так яснее?

Изменено пользователем Lampus

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

ну и сам трекер пропатчить таким образом чтоб прежде чем ответить, смотрел в какой сети есть нужный файл. добавить пару условий к sql запросу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если сам сервер патчить, то проще уж тогда не отдавать клиенту тех пиров, которые находятся в других подсетях, если есть ещё пиры в клиентской.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>ну и сам трекер пропатчить таким образом чтоб прежде чем ответить, смотрел в какой сети есть нужный файл. добавить пару условий к sql запросу.

 

Ещё один аргумент против xbtt. Всяко проще подправить sql-запрос, чем ковыряться в памяти(xbtt в "анонимном" режиме(а именно он и нужен автору темы) вообще работает без базы данных, всё держит в памяти)

 

И ещё нужно выяснить, какой аплинк у подъездных коммутаторов, если 100 мегабит, то ничего хорошо не выйдет, т.к. вы очень скоро будете мешать своим соседям и провайдер что-нибудь сделает с вами.

 

>Если сам сервер патчить, то проще уж тогда не отдавать клиенту тех пиров, которые находятся в других подсетях, если есть ещё пиры в клиентской.

 

А разве кто-то что-то другое предлагал?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

> И ещё нужно выяснить, какой аплинк у подъездных коммутаторов, если 100 мегабит, то ничего хорошо не выйдет, т.к. вы очень скоро будете мешать своим соседям и провайдер что-нибудь сделает с вами.

 

Все провы исполльзуют FTTx, то бишь до дома доходит оптический кабель, над каждым подъездом ставятся 24-портовые (как правило) свитчи как минимум с двумя гигабитными SFP портами.

Входные условия слегка изменились, один из провов, после беседы с их тех. директором, у меня будет теперь на гигабитном канале, но сути шибко не меняет.

 

> Ещё один аргумент против xbtt. Всяко проще подправить sql-запрос, чем ковыряться в памяти(xbtt в "анонимном" режиме(а именно он и нужен автору темы) вообще работает без базы данных, всё держит в памяти)

 

Я представляю что такое xbtt, ковырялся... Там чёрт ногу сломит, ни документации, ни даже банальных комментариев в коде. Мне понадобилось два часа мучений с grep -in keyword * что бы откопать где список пиров отдаётся. Но как я уже говорил, машинка не ахти, посему вешать на неё php-шный трекер не хотелось бы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но как я уже говорил, машинка не ахти, посему вешать на неё php-шный трекер не хотелось бы.
вы сами себе противоречите. а как вы тогда трафик через нее прокачивать собрались? пхп потребует заметно меньше ресурсов чем проксирование.

 

вообще 50 тыс пиров/5тыс пользователей съедают всего 10% от пентиум4 2.4ггц (древний сокет 478). причем частота запросов трекера максимальная выставлена.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пхп потребует заметно меньше ресурсов чем проксирование
ДА НУ!

фряха + kqueue совсем не много жрут.

Для тупого проксирования там кода три строки: получил - переслал - получаю ещё -...

Нагрузка ляжет на дрова/прерывания, и копирование из юзерспейс в ядро и обратно. Может есть способ проксирования без копирования, но без писания модуля для ядра я такого не нашёл/не сильно искал.

 

Итого: всё ограничивается простым копированием из юзерспейс в кернел и обратно, а пхп тоже самое + куча кода.

Хотя если с пхп отдавать ответ: иди копируй оттуда, то будет экономия в сравнении с проксированием хотя бы 100 мегабайт файла.

 

 

Ещё есть вариант переписать клиента чтобы он через вас гонял.

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

В пределе можно попробовать сразу вас писать всем сокс проксёй.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.