Live dc++ forum
Форма входа
Логин:
Пароль:
Главная | Проблема пассивного режима в DC. Сервер-медиатор для клиента - Страница 2 - Форум | Вторник, 24.10.2017, 12:43
[ Новые сообщения · Участники · Правила форума · Поиск
Страница 2 из 3«123»
Форум » >> » ToDo » Проблема пассивного режима в DC. Сервер-медиатор для клиента
Проблема пассивного режима в DC. Сервер-медиатор для клиента
dolchegobanoДата: Воскресенье, 21.06.2009, 19:28 | Сообщение # 1
Сержант
Сообщений: 34
Репутация: 0
Статус: Offline
У меня есть ряд вопросов и кое-какие бредовые идеи smile
Почему бы хабу не взять на себя функции сервера-медиатора, который будет соединять пассивных юзеров друг с другом? Существует софт, который делает это: например пресловутый Скайп или вот такая штучка - http://wippien.com/mediator.php
Если в Грейлинке есть функция веб-сервера и возможность создания мини-хабов, то почему бы не научить Грейлинк доброму делу для братьев наших меньших — перенаправлению запросов между пассивными юзерами?
Сразу признаюсь — у меня очень поверхностные знания о сетевых технологиях, и я многого не понимаю. Программировать тоже не умею. Я просто продвинутый юзер smile Прошу просветить, если я заблуждаюсь.
На хабах бывает очень много пассивных юзеров, и с ними надо что-то делать. Если непосредственно на хаб будет большая нагрузка, то почему бы не перенести часть обязанностей на плечи (компы) юзеров с выделенным IP? Как это может выглядеть на практике: пассивный юзер ищет среди знакомых активного, который включит для него галочку в своём клиенте. Благодаря галочке пассивный друг сможет скачивать на этом хабе с других пассивов.
Есть другой вариант: админ хаба раздаёт пассивным юзерам право качать с других пассивов (типа VIP-пассивки smile То есть некая привилегия для обладателей большой шары, но не имеющих выделенного ипа. Может быть, сервер-медиатор будет реализован в виде обслуживающего бота.

Короче, надо что-то делать с пассивными юзерами, коих очень и очень много. Порой у них очень интересные и полезные шары, а процессорные мощности и пропускные каналы некоторых хабов и активов просто простаивают.

У кого есть какие суждения по этой проблеме?


гей-хаб 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 это отсутствие окон
соответственно никаких мер по контролю,
мало ли много ли данных за раз передаётся, нет, только определение эмпирическим путём smile что и будет вызывать дикие перегрузки в сетях
однако если подойти к этому по уму и при установлении поточного соединения договорится с клиентом на той стороне сколько же ему хорошо, то проблем будет уже намного меньше

ps: и если пойдёт потеря пакетов, переваливающая за 10-15% это в любом случае будет }|{опа smile
но для 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 эмм smile дыру закидывать

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
предложу, но чуть позже smile пока думаю ка бы это всё между собой "совокупить"

STUN client version 0.94
Primary: Port Restricted Nat, random port, will hairpin
Return value is 0x3
но это своё, домашнее…

4e4ako спасибо smile

Добавлено (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=17857&#entry17857

Добавлено (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, а нат свой самодельный...

как раз важно. пользователь самодельного НАТа могут стать активами, если приложат руки и голову. а провайдерский НАТ пока не изучен smile
 
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к абонентов sad


Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 00:40
 
hmuryДата: Пятница, 03.07.2009, 00:41 | Сообщение # 30
Генерал-лейтенант
Сообщений: 599
Репутация: 32
Статус: Offline
Quote (4e4ako)
региональная сетка ~15к абонентов

радуйся wink после апгрейда uTorrent до 1.9.x будешь качать и с пассивных пиров wink
 
Форум » >> » ToDo » Проблема пассивного режима в DC. Сервер-медиатор для клиента
Страница 2 из 3«123»
Поиск:


В движке поковырялся LiveDC :p © 2017
Сделать бесплатный сайт с uCoz