|
Проблема пассивного режима в DC. Сервер-медиатор для клиента
|
|
| dolchegobano | Дата: Воскресенье, 21.06.2009, 19:28 | Сообщение # 1 |
Сержант
Сообщений: 34
Репутация: 0
Статус: Offline
| У меня есть ряд вопросов и кое-какие бредовые идеи 
Почему бы хабу не взять на себя функции сервера-медиатора, который будет соединять пассивных юзеров друг с другом? Существует софт, который делает это: например пресловутый Скайп или вот такая штучка - http://wippien.com/mediator.php
Если в Грейлинке есть функция веб-сервера и возможность создания мини-хабов, то почему бы не научить Грейлинк доброму делу для братьев наших меньших — перенаправлению запросов между пассивными юзерами?
Сразу признаюсь — у меня очень поверхностные знания о сетевых технологиях, и я многого не понимаю. Программировать тоже не умею. Я просто продвинутый юзер Прошу просветить, если я заблуждаюсь.
На хабах бывает очень много пассивных юзеров, и с ними надо что-то делать. Если непосредственно на хаб будет большая нагрузка, то почему бы не перенести часть обязанностей на плечи (компы) юзеров с выделенным IP? Как это может выглядеть на практике: пассивный юзер ищет среди знакомых активного, который включит для него галочку в своём клиенте. Благодаря галочке пассивный друг сможет скачивать на этом хабе с других пассивов.
Есть другой вариант: админ хаба раздаёт пассивным юзерам право качать с других пассивов (типа VIP-пассивки То есть некая привилегия для обладателей большой шары, но не имеющих выделенного ипа. Может быть, сервер-медиатор будет реализован в виде обслуживающего бота. Короче, надо что-то делать с пассивными юзерами, коих очень и очень много. Порой у них очень интересные и полезные шары, а процессорные мощности и пропускные каналы некоторых хабов и активов просто простаивают. У кого есть какие суждения по этой проблеме?
гей-хаб dchub://queers.dyndns.org
|
| |
|
|
| 4e4ako | Дата: Пятница, 03.07.2009, 00:45 | Сообщение # 31 |
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (hmury) радуйся после апгрейда uTorrent до 1.9.x будешь качать и с пассивных пиров
уже юзал альфу - толку "0"
ни обхода шейпера (что наблюдается у скайпа частенько), ни увеличения коннектов 
от ipv6 туннелинга толку и то больше..
|
| |
|
|
| hmury | Дата: Пятница, 03.07.2009, 00:48 | Сообщение # 32 |
Генерал-лейтенант
Сообщений: 599
Репутация: 32
Статус: Offline
| Quote (4e4ako) уже юзал альфу - толку "0"
тут проблема с пирами. все должны проапгрейдить клиент на поддержку UDP-соединений
в дц++, даже если сделать, тоже пройдут годы, прежде чем станет заметен результат
|
| |
|
|
| 4e4ako | Дата: Пятница, 03.07.2009, 00:55 | Сообщение # 33 |
|
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (hmury) клиент на поддержку UDP-соединений
bittorrent, если не изменяет память уже несколько лет поддерживает udp - для него и трекеры с udp анонсами делали.. в общем udp соединения были и много (uTP - флаг) - иногда даже больше чем обычных, но результата не было видно.
Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 01:52 |
| |
|
|
| IRainman | Дата: Пятница, 03.07.2009, 01:03 | Сообщение # 34 |
|
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| http://clip2net.com/clip/m14997/1246567695-clip-16kb.png
и
STUN client version 0.94
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b
ps: провайдер: тоже акадо, Москва, точнее Зеленоград, подключение по эзернету, количество пользователей около 10тыс.
но это уже провайдерский натДобавлено (03.07.2009, 01:03)
---------------------------------------------
завтра ещё инфу с нескольких сеток по окрестностям выложу
а сейчас спааать
Официальный сайт FlylinkDC++
Блог разработчиков FlylinkDC++
Сообщение отредактировал IRainman - Пятница, 03.07.2009, 00:58 |
| |
|
|
| 4e4ako | Дата: Пятница, 03.07.2009, 14:20 | Сообщение # 35 |
|
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote STUN client version 0.94
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b
однако вот что мне показал родимый мастдай: Quote C:\>netsh interface ipv6 show teredo
Параметры Teredo
---------------------------------------------
Тип : client
Имя сервера : teredo.ipv6.microsoft.com
Интервал обновления клиента: 60 секунд
Порт клиента : 34567
Состояние : offline
Ошибка : клиент за симметричным NAT Добавлено (03.07.2009, 14:20)
---------------------------------------------
посмотрел пакетным снифером что он делает..
не похоже, что он работает "правильно" - т.к. пакеты получил только с 1 адреса(на который и отправлял), а ведь для полноценного теста нужно 2 внешних сервера?
или я че то напутал?
|
| |
|
|
| SMT | Дата: Пятница, 03.07.2009, 14:49 | Сообщение # 36 |
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (4e4ako) посмотрел пакетным снифером что он делает..
не похоже, что он работает "правильно" - т.к. пакеты получил только с 1 адреса(на который и отправлял), а ведь для полноценного теста нужно 2 внешних сервера?
или я че то напутал?
а я покопался в исходниках этого сервера-клиента. случай, когда сессия может быть продолжена с другого IP, у них называется "Full-Cone NAT". так называемый "Port Restricted Nat" означает, что пакеты должны приходить с того же IP и на тот же порт назначения, пакет с которого открыл NAT. это усложняет процесс, но не делает его невозможным.
|
| |
|
|
| IRainman | Дата: Пятница, 03.07.2009, 15:18 | Сообщение # 37 |
|
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| Quote А, ну у меня IPv4 SNAT & DNAT. Ядро 2.6.24 Realtime. Провайдер - NBN (NetByNet). Это с компа за роутером. STUN client version 0.94
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b
Официальный сайт FlylinkDC++
Блог разработчиков FlylinkDC++
|
| |
|
|
| 4e4ako | Дата: Пятница, 03.07.2009, 15:46 | Сообщение # 38 |
|
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (SMT) означает, что пакеты должны приходить с того же IP...
+с того же порта на который вы отправляли данные.. но тогда это ничем не отличается от установленного и поддерживаемого соединения..
т.е. для соединения двух пассивов в таком режиме они будут долбить шлюзы друг друга пока не получится установить коннект? веселая теория ^ ^ тестилка от Мюнхенского университета информатики:
http://nattest.net.in.tum.de/ показала тоже самое "port restricted"
Quote Your NAT-Box has the following properties: Port restricted NAT detected
Preserves port number Does not support hairpin of media
No UPnP-Device found. no UPnP device found Testing UDP... UDP Hole Punching successful Testing TCP...sending testing request... TCP HolePunching (low TTL) not successful Testing TCP...sending testing request... TCP HolePunching (high TTL) successful
Testing TCP...sending fake FTP-Request... PORT 192,168,0,1,67,48
TCP HolePunching (FTP-ALG) not successful а я тут подумал а как же таймауты? если соединение разорвано на stun сервере это еще не значит, что шлюз провайдера все еще не ждет ответа от него.. который stun сервер через секунду ему и посылает думая, что он устанавливает новое соединение... хм.. что то намудрили мы тут )))
Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 17:31 |
| |
|
|
| SMT | Дата: Пятница, 03.07.2009, 17:36 | Сообщение # 39 |
|
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (4e4ako) +с того же порта на который вы отправляли данные.. но тогда это ничем не отличается от установленного и поддерживаемого соединения..
т.е. для соединения двух пассивов в таком режиме они будут долбить шлюзы друг друга пока не получится установить коннект? веселая теория ^ ^
теория имхо такая 1. Full-Cone NAT, random port клиент1 посылает на STUN UDP-пакет с порта xx, он через NAT меняет порт на yy и STUN рапортует, что внешний IP=z.z.z.z, порт сменён с xx на yy.
клиент1 через хаб говорит клиенту2 ConnectToMe z.z.z.z:yy 2. Port Restricted NAT, preserved port клиент1 слушает UDP-порт xx, клиент2 порт yy. на ADC-хабах UDP-порт известен для всех активных клиентов, NMDC-хабы видимо не будут поддерживаться клиент1 посылает клиенту2 через хаб ConnectToMe xx и бросает пакет на порт yy клиенту2.
пакет создаёт NAT-правило:
внешний IP=клиент2-роутер, внешний порт=yy, внутренний порт=xx, внутренний IP=клиент1 клиент2 посылает пакет клиенту1 с порта yy на порт xx и создаёт в своём NAT аналогичное правило неудобно то, что оба случая реализуются разными алгоритмами, избыточность получается
|
| |
|
|
| 4e4ako | Дата: Пятница, 03.07.2009, 18:10 | Сообщение # 40 |
|
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (SMT) клиент1 слушает UDP-порт xx, клиент2 порт yy. на ADC-хабах UDP-порт известен для всех активных клиентов, NMDC-хабы видимо не будут поддерживаться
в коннекттоми все равно придется еще дописывать с какого порта клиент2 должен инициировать подключение.. дабы если все будут ломиться на один порт будет работать коряво.. ну главное научить клиентов узнавать за каким типом НАТа они и в зависимости от этого - правильно отсылать\получать команды "коннекттоми".
Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 18:44 |
| |
|
|
| SMT | Дата: Пятница, 03.07.2009, 18:57 | Сообщение # 41 |
|
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (4e4ako) в коннекттоми все равно придется еще дописывать с какого порта клиент2 должен инициировать подключение
в любом случае, в adc-команды можно дописывать любые свои параметры, как и в INF-тег клиента. nmdc фильтрует всё лишнее Quote (4e4ako) дабы если все будут ломиться на один порт будет работать коряво.. я думал наоборот, один слушающий udp-сокет будет эффективнее. он будет выполнять роль сетевого интерфейса в эмулируемом tcp-стеке. а клиенты могут мультиплексироваться tcp-портом из полного tcp-пакета, который будет в payload-части udp-пакета
|
| |
|
|
| 4e4ako | Дата: Пятница, 03.07.2009, 19:13 | Сообщение # 42 |
|
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
| Quote (SMT) я думал наоборот, один слушающий udp-сокет будет эффективнее. я имел ввиду что если все будут ломиться на этот порт, то клиент-2 не сможет одновременно передавать данные с одного порта для нескольких клиентов-1.. или мои познания еще не доросли до понимания сетевых протоколов?
|
| |
|
|
| SMT | Дата: Пятница, 03.07.2009, 19:22 | Сообщение # 43 |
|
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
| Quote (4e4ako) я имел ввиду что если все будут ломиться на этот порт, то клиент-2 не сможет одновременно передавать данные с одного порта для нескольких клиентов-1.. или мои познания еще не доросли до понимания сетевых протоколов?
udp-сокет не имеет таких ограничений. src ip/port прибиндены. dst ip/port указываются с каждым пакетом
|
| |
|
|
| IRainman | Дата: Пятница, 03.07.2009, 22:53 | Сообщение # 44 |
|
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
| ммм, смотрю дело движется
даже не имхо а точно
единственное уя вот чего не пойму
что если будет такая ситуация: конечный юзер сидит за роутером, а роутер в свою очередь подключён к сетке, где соответсвенно имеется второй(провайдерский) НАТ т.е. надо как то цепочки предусмотреть…
с ADC будет проще, но всё равно цепочка получится Quote неудобно то, что оба случая реализуются разными алгоритмами, избыточность получается
это да ps:
Primary: Address Restricted Nat, random port, will hairpin
Return value is 0x2
это с роутера DLINK DI-524, IP выделенный
чувствуется что все кто сидит за роутерами проблем не испытают
Официальный сайт FlylinkDC++
Блог разработчиков FlylinkDC++
|
| |
|
|
| dolchegobano | Дата: Понедельник, 16.11.2009, 12:41 | Сообщение # 45 |
|
Сержант
Сообщений: 34
Репутация: 0
Статус: Offline
| ну так как продвигается работа над проблемой пассивного режима?
***
В последнее время для обмена файлами с друзьями (тоже сидящими за натом) я пользуюсь Gbridge - весьма простая и эффективная софтина. Неужели нельзя прикрутить что-то подобное к дц-клиенту или хабу?
гей-хаб dchub://queers.dyndns.org
|
| |
|
|
