Close Topic Options

v0.64 2006.4.10
GUI Improved: the optional IE toolbar is removed
GUI Improved: able to read RSS feed
GUI Bugfix: chat user list is removed temporarily
Core Bugfix: fix the bug that the play button doesn't work after click stop button in task preview window
Core Bugfix: fix the bug that unable to seek continous when preview avi/rm file

так и хочется приписать -

master bug fix: banned on our tracker.

FiL

на самом деле для "счастливых" обладателей LowID пока лишь комета позволяет обходить NAT

Не, в данный момент я злой на азура
некий пользователь Х, анонс каждые 2.24 минуты, среднее кол-во запросов на торрент 21684.91

@$#%#%^@#$% !#@#$%@#$^% @#$%!#$% Как только выйдет азур 2.4.0.3 или какой там у них по плану - все старые азуры будут забанены к чёртвой матери...

А если в 2.4.0.3 не пофиксят это - то я за себя не отвечаю

Комета решила свои проблемы, ведет себя прилично - замечательно. Забанить кометы была не самоцель....

Уже не раз обсуждалось, но так и не пришлось к окончательному выводу. Комета в любом случае помогает при LOW ID обойти NAT и получить OK? Или тока при стечении других обстоятельств? Если ДА, то каких?

Комета помогает только в одном случае - если две кометы имеют LowID, то они смогут обмениваться друг с другом. Только кометы и только друг с другом На статус ОК это никак не влияет... По идее на нашем трекере толку от этого должно быть 0 - LowID не отдается клиентам и как бы обмен источниками по уверениям создателя кометы тоже не должен работать - поэтому по логике вещей два LowID не должны знать друг о друге...

именно так у меня не раз выручала Комета, причём надо, чтобы у всех Комет была включена опция обхода NAT!

Ну понятно. Коза с баяном еще та. У меня просто был момент между удачным обходом МЮшкой лоу ид и получения OK (т.е. полного шоколада), что имели ЛОУ ИД, не было обмена с такими ЛОУ ИД-ешниками. Комета тоже не помогала. Ну значит было дело не во мне. А щас вроде МЮ опять заработала и проблема подзабылась, но решил выяснить до конца. Спасибки

Хмм, есть другое мнение ... Итак, спекуляция чистой воды - как лично я реализовывал бы NAT Traversal на месте автора BitComet.

У клиентов A и B (оба с LowID) в настройках стоит "NAT Traversal = Yes". При соединении с клиентом X они оба ему рассказывают (как служебный трафик, присущий только BitComet'ам между собой), что были бы не прочь делать NAT Traversal.

Когда клиент X видит желающих делать NAT Traversal в списке пиров задачи (т.е. участников одной и той же раздачи), то говорит им "ну, давайте попробуем, ребята". Дальше они под его руководством пытаются соединиться между собой как описано в Wikipedia: UDP hole punching

мысль интересная, клиент Х правда должно помнить что есть какие-то ЛоуИД которые что-то там хотят. Причем они хотят в разное время - т.е. приходит один ЛоуИД и говорит я ЛоуИД... потом второй через пару часов... И наш клиент Х героически помнит об этом... Я надеюсь что азур\мю сделают "офф" версию, как они сделали с шифрованием, вот тогда будет куда лучче...

ludde's working on NAT traversal

Скорее всего можно в скорых беттах ожидать эту фишку.

я бы желал иметь это для любых клиентов - в смысле не мю с мю, комета с кометой, а как с шифрованием - стандарт, который поддерживают все правильные клиенты

а вам не кажется, что это немножко бредового, два лоуид могут качать друг от друга? а весьэтот NAT Traversal всего лишь uPnP и управление политикой фаервола

Обсуждаемый тут NAT Traversal - это не в широком смысле этого слова (разные пути борьбы с LowID, в основном методом получения у себя HighID), а в узком - конкретная галочка "Use NAT Traversal via UDP" в настройках BitComet. Именно для соединения двух клиентов с LowID.

Еще добавлю, что если эта фича работает, то в BitComet на вкладке Peers в столбце Initiation можно увидеть пиров не Local и не Incoming, а именно NAT Traversal.

вы где такую траву берете????