|
Главная | Проблема пассивного режима в DC. Сервер-медиатор для клиента - Страница 2 - Форум | Пятница, 29.03.2024, 02:13
Проблема пассивного режима в DC. Сервер-медиатор для клиента
| |
dolchegobano | Дата: Воскресенье, 21.06.2009, 19:28 | Сообщение # 1 |
Сержант
Сообщений: 34
Репутация: 0
Статус: Offline
| У меня есть ряд вопросов и кое-какие бредовые идеи Почему бы хабу не взять на себя функции сервера-медиатора, который будет соединять пассивных юзеров друг с другом? Существует софт, который делает это: например пресловутый Скайп или вот такая штучка - http://wippien.com/mediator.php Если в Грейлинке есть функция веб-сервера и возможность создания мини-хабов, то почему бы не научить Грейлинк доброму делу для братьев наших меньших — перенаправлению запросов между пассивными юзерами? Сразу признаюсь — у меня очень поверхностные знания о сетевых технологиях, и я многого не понимаю. Программировать тоже не умею. Я просто продвинутый юзер Прошу просветить, если я заблуждаюсь. На хабах бывает очень много пассивных юзеров, и с ними надо что-то делать. Если непосредственно на хаб будет большая нагрузка, то почему бы не перенести часть обязанностей на плечи (компы) юзеров с выделенным IP? Как это может выглядеть на практике: пассивный юзер ищет среди знакомых активного, который включит для него галочку в своём клиенте. Благодаря галочке пассивный друг сможет скачивать на этом хабе с других пассивов. Есть другой вариант: админ хаба раздаёт пассивным юзерам право качать с других пассивов (типа VIP-пассивки То есть некая привилегия для обладателей большой шары, но не имеющих выделенного ипа. Может быть, сервер-медиатор будет реализован в виде обслуживающего бота. Короче, надо что-то делать с пассивными юзерами, коих очень и очень много. Порой у них очень интересные и полезные шары, а процессорные мощности и пропускные каналы некоторых хабов и активов просто простаивают. У кого есть какие суждения по этой проблеме?
гей-хаб dchub://queers.dyndns.org
|
|
|
|
SMT | Дата: Четверг, 02.07.2009, 21:24 | Сообщение # 16 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| http://habrahabr.ru/blogs/p2p/45989/ в комментариях пишут, что с переводом p2p на UDP настанет конец интернета
|
|
|
|
IRainman | Дата: Четверг, 02.07.2009, 22:17 | Сообщение # 17 |
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| ооооо ееее) единственная капитальная проблема UDP это отсутствие окон соответственно никаких мер по контролю, мало ли много ли данных за раз передаётся, нет, только определение эмпирическим путём что и будет вызывать дикие перегрузки в сетях однако если подойти к этому по уму и при установлении поточного соединения договорится с клиентом на той стороне сколько же ему хорошо, то проблем будет уже намного меньше ps: и если пойдёт потеря пакетов, переваливающая за 10-15% это в любом случае будет }|{опа но для p2p наверняка эта 5я точка перекроется возможностями броадкаста, что в теории не только не убъёт интернет а разгрузит его… пост пыпысы: почитал, проникся, спасибо за наводку, очень пригодится там кстати высказана интересная мысль что не требуется не последовательной передачи данных, не нумерации пакетов, ни ответов источнику, просто контроль кусков(мб блоков) у получателя и запрос их по новой в случае чего чуется надо к DC такое прикручивать, мысль шикарная
Официальный сайт FlylinkDC++ Блог разработчиков FlylinkDC++
Сообщение отредактировал IRainman - Четверг, 02.07.2009, 22:40 |
|
|
|
SMT | Дата: Четверг, 02.07.2009, 22:42 | Сообщение # 18 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (IRainman) но для p2p наверняка эта 5я точка перекроется возможностями броадкаста, что в теории не только не убъёт интернет а разгрузит его… броадкастов нет в интернете, а мультикасты от простых юзеров не маршрутизируются провайдерами
|
|
|
|
SMT | Дата: Четверг, 02.07.2009, 22:53 | Сообщение # 19 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (IRainman) там кстати высказана интересная мысль что не требуется не последовательной передачи данных, не нумерации пакетов, ни ответов источнику, просто контроль кусков(мб блоков) у получателя и запрос их по новой в случае чего чуется надо к DC такое прикручивать, мысль шикарная сложно. не сколько это мне нравится, сколько возможность прямого соединения пассивных с помощью долбления udp-дыры. проще всего реализовать подобие tcp поверх udp и весь остальной протокол оставить потоковым без изменений. а при коннекте указывать как-то, что юзается udp-коннект, а не tcp-коннект
|
|
|
|
4e4ako | Дата: Четверг, 02.07.2009, 23:30 | Сообщение # 20 |
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (SMT) не сколько это мне нравится, сколько возможность прямого соединения пассивных с помощью долбления udp-дыры. скайп уже давно использует.. он вообще по хитростям с обходом NAT-ов "впереди планеты всей".. но в "серых" сетях (коих в России "бесчисленное множество") это не работает.. вообще симметричный NAT ничем не прошибешь, кроме банального туннелинга - http://en.wikipedia.org/wiki/TURN p/s ваша ссылка, но на русском (кому интересно) http://ru.wikipedia.org/wiki/STUN
Сообщение отредактировал 4e4ako - Четверг, 02.07.2009, 23:30 |
|
|
|
IRainman | Дата: Четверг, 02.07.2009, 23:34 | Сообщение # 21 |
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| Quote броадкастов нет в интернете, а мультикасты от простых юзеров не маршрутизируются провайдерами на счёт инета полностью согласен, спасибо, ошибся я, но на счёт мульикастов внутри сети это не всегда верно Quote проще всего реализовать подобие tcp поверх udp имхополучим снижение производительности и довольно сильное, с реализацией так быстрее получится это факт, хотя и как то "в раскоряку" но ведь куда полезней переписать пересылку блока посредством udp, правда в этом случае потребуется реорганизация сборки блока…, а уже полученное в UDP эмм дыру закидывать ps: к тому же этот вариант вполне вероятно будет поддержан в клиентах-прародителях, а после стандартизации легко приживётся как расширение протокола [добавлено] просто если уж делать, а проблем всё равно будет много, то делать универсально, так и UDP передача будет которая в локалках особенно эффективна, и возможность использовать полученные пакеты для организации соединения между пассивами
Официальный сайт FlylinkDC++ Блог разработчиков FlylinkDC++
Сообщение отредактировал IRainman - Четверг, 02.07.2009, 23:41 |
|
|
|
SMT | Дата: Четверг, 02.07.2009, 23:59 | Сообщение # 22 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| 4e4ako> но в "серых" сетях (коих в России "бесчисленное множество") это не работает.. 4e4ako> вообще симметричный NAT ничем не прошибешь я тоже сначала так подумал и скептически отнёсся к идее. но реальные эксперименты показали, что провайдеры предоставляют Port Restricted NAT, а не Symmetric. а ADSL-модемы, так вообще Full-Cone NAT предлагаю скачать http://prdownloads.sourceforge.net/stun/client.exe?download и выполнить: C:\NAT_TEST> client.exe stun.xten.com когда я зашёл в VPN-сеть очень мелкого провайдера и попросил админа предоставить NAT средствами ipfw во FreeBSD, как обычным клиентам, я получил: STUN client version 0.94 Primary: Port Restricted Nat, preserves ports, no hairpin Return value is 0x1b модем Zyxel P600RU в режиме "роутер" даёт C:\NAT_TEST> client.exe stun.xten.com STUN client version 0.94 Primary: Full Cone Nat, random port, no hairpin Return value is 0x9 если бы кто-то мог протестировать это в серой сети крупного провайдера, было бы лучше понятно, насколько идея STUN актуальна в России. к сожалению, у этого форума слишком мало читателей, чтобы составить статистику IRainman>> имхополучим снижение производительности и довольно сильное, IRainman>> с реализацией так быстрее получится это факт, хотя и как то "в раскоряку" да. но лучше так, чем никак. иначе "в раскорячку" встанет система слотов и лимитеров клиента. если перейти на свободную отдачу фрагментов через UDP по приходу UDP-запроса, это будет скорее в духе торрента, плохо скажется на TransferFrame и WaitingUsersFrame мне кажется, с этими проблемами столкнётся StrongDC+DHT, если он всё-таки перейдёт на UDP для файлов. посмотрим, что он придумает IRainman>> просто если уж делать, а проблем всё равно будет много, то делать универсально предложи протокол ))
|
|
|
|
SMT | Дата: Пятница, 03.07.2009, 00:05 | Сообщение # 23 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (IRainman) имхополучим снижение производительности и довольно сильное какая разница, оверхед у TCP порядка 2-3%. на TCP+UDP будет 4-5%. если взять TCP-стек, скажем, от линукса, но результат писать не в ip-пакет, а в udp-пакет, то никакой лажи с кривой реализацией сессии поверх upd не будет
|
|
|
|
IRainman | Дата: Пятница, 03.07.2009, 00:20 | Сообщение # 24 |
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| SMT предложу, но чуть позже пока думаю ка бы это всё между собой "совокупить" STUN client version 0.94 Primary: Port Restricted Nat, random port, will hairpin Return value is 0x3 но это своё, домашнее… 4e4ako спасибо Добавлено (03.07.2009, 00:20) ---------------------------------------------
Quote какая разница, оверхед у TCP порядка 2-3%. на TCP+UDP будет 4-5%. если взять TCP-стек, скажем, от линукса, но результат писать не в ip-пакет, а в udp-пакет, то никакой лажи с кривой реализацией сессии поверх upd не будет это да, но всю обработку придётся вести программно ну а так соглашусь, из быстрого решения это именно то что нужно
Официальный сайт FlylinkDC++ Блог разработчиков FlylinkDC++
|
|
|
|
SMT | Дата: Пятница, 03.07.2009, 00:26 | Сообщение # 25 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (IRainman) это да, но всю обработку придётся вести программно это меня смутило. TCP и так в винде програмный. нахождение кода в юзермоде или кернел-моде не влияет на скорость. влияет только радиус кривизны кода. есдинственный ой это размер исходников tcp в kernel.org, полметра
|
|
|
|
hmury | Дата: Пятница, 03.07.2009, 00:27 | Сообщение # 26 |
Генерал-лейтенант
Сообщений: 599
Репутация: 32
Статус: Offline
| Quote (IRainman) но это своё, домашнее… это какой провайдер? это серая сеть? вроде за НАТом. открытый инет говорит "No NAT Present (Open)"
|
|
|
|
IRainman | Дата: Пятница, 03.07.2009, 00:31 | Сообщение # 27 |
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| Quote TCP и так в винде програмный. а это меня убило… не знал что так всё плохо… тогда да, всё вообще шикарно, кроме небольших накладных расходов на оверхед ps: зазеркалил сообщение тут http://mydc.ru/topic2127.html?gopid=17857entry17857Добавлено (03.07.2009, 00:31) ---------------------------------------------
Quote (hmury) это какой провайдер? это серая сеть? вроде за НАТом. открытый инет говорит "No NAT Present (Open)" это Акадо, Москва, но это не важно, у меня внешний IP, а нат свой самодельный...
Официальный сайт FlylinkDC++ Блог разработчиков FlylinkDC++
|
|
|
|
hmury | Дата: Пятница, 03.07.2009, 00:38 | Сообщение # 28 |
Генерал-лейтенант
Сообщений: 599
Репутация: 32
Статус: Offline
| Quote (IRainman) это Акадо, Москва, но это не важно, у меня внешний IP, а нат свой самодельный... как раз важно. пользователь самодельного НАТа могут стать активами, если приложат руки и голову. а провайдерский НАТ пока не изучен
|
|
|
|
4e4ako | Дата: Пятница, 03.07.2009, 00:39 | Сообщение # 29 |
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (SMT) STUN client version 0.94 Primary: Port Restricted Nat, preserves ports, no hairpin Return value is 0x1b региональная сетка ~15к абонентов
Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 00:40 |
|
|
|
hmury | Дата: Пятница, 03.07.2009, 00:41 | Сообщение # 30 |
Генерал-лейтенант
Сообщений: 599
Репутация: 32
Статус: Offline
| Quote (4e4ako) региональная сетка ~15к абонентов радуйся после апгрейда uTorrent до 1.9.x будешь качать и с пассивных пиров
|
|
|
|
|
|
|