• Рейтинг трекеров рунета

      Закончился 2009 год, начинается новое десятилетие, с чем я от души поздравляю всех читателей! P2P стал одним из важных явлений прошедшего десятилетия, и его популярность уменьшаться не собирается. Например, в 2009 году у двух сериалов — Heroes и Dexter — число скачиваний превысило число телевизионных просмотров. В России p2p-файлообмен, можно сказать, в минувшем десятилетии и появился. Какие-то тренды проходят мимо нас, что-то становится популярнее чем в мире (ICQ, броузер Opera), появившийся в 1999-м году Napster вобщем-то прошел мимо нас, как и LimeWire, а первым популярным P2P протоколом у нас стал ed2k, официальный клиент которого уже давно закрыт, но остались альтернативы типа eMule.
      Читать дальше →
    • Асинхронная загрузка произвольного html

        В связи с последними инициативами гугла учитывать время загрузки страницы становится всё более актуально асинхронно подгружать части веб-страниц уже после загрузки основного минимума. Реклама — один из претендентов на отложенную загрузку, но простой ajax тут не поможет, т.к. в общем случае в подгружаемом куске может встречаться, например, document.write, и если документ уже загружен и закрыт то данный метод открывает его заново, обнуляя при этом.

        Гугл в этом плане не сильно помогает, т.к. основной описываемый метод — подмена document.write своим собственным методом, который тупо добавляет аргумент в конец документа, но если вызов идёт не в конце и писать надо куда-то в середину — возникает проблема. На хабре описывался фрейморк Fullajax, который вроде справляется с этим, но как именно — я пока не смотрел.

        У меня возникла другая идея, возможно — велосипед, но желание попробовать было слишком сильным. А именно, подгружать отложенный код в скрытый iframe, а после загрузки переносить его содержимое туда, где оно должно быть. Более того, чтобы не делать лишних запросов к серверу, используется data URI. Такой подход работает в FF и Opera но не работает в IE и Chrome.
        Читать дальше →
      • Про µTP в новых версиях µTorrent: что это, как, зачем?

          Традиционно большинство P2P-приложений использовало TCP для обмена данными. Про то, что µTorrent начинает использовать новый протокол, основанный на UDP, на хабре уже упоминали (раз, два). В данном посте новый протокол µTP описан подробнее, в том числе его тюнинг и возможность отключения. Подробности описаны таким образом, чтобы было понятно далёким от сетевых протоколов людям.

          Update: Официальная документация на протокол: www.bittorrent.org/beps/bep_0029.html
          Читать дальше →
        • IPv6 для P2P

            IPv6 обычно ассоциируется с проблемой нехватки IPv4 адресов, о которой любит писать «желтая» пресса. Что со дня на день свободных адресов не останется и переход на IPv6 будет неизбежен. Скептики считают что проблема настолько же раздута, как в своё время «ошибка 2000», когда все боялись что после 1999 года наступит 1900 и случится техногенная катастрофа.

            Для большинства пользователей, действительно, пользы от IPv6 никакой. Какая разница, например, что заголовки пакетов более удобны для маршрутизатора? Но для P2P проблема NAT (за счёт чего IPv4-адреса так ещё и не закончились) реальна, т.к. для связи peer-to-peer (даже чтобы переслать файл через Jabber или ICQ) нужно чтобы хотя бы один из участников был доступен снаружи, т.е. имел реальный IP-адрес или хотя бы пробросил себе порт. Некоторые провайдеры предоставляют внешний адрес за отдельную плату, у некоторых такой возможности нет, и именно для NAT-страдальцев будет больше всего полезно использование IPv6.

            Также это будет полезно тем, у кого провайдер режет p2p-трафик. В России это (пока?) не так распространено, а за рубежом — далеко не редкость. IPv6 трафик (точнее, обёрнутый в обычные UDP пакеты) ими не режется. Еще это может помочь в ситуации, когда p2p-трафик блокируется корпоративным фаерволом, но настроить IPv6 через туннель можно.
            Читать дальше →
          • Обслуживание тысяч запросов в секунду на примере XBT Tracker

              Недавно проводили тест, результаты которого показали, что одно приложение обрабатывает 2000 запросов в секунду на скромном сервере, где это было не единственной нагрузкой. При этом результат каждого запроса записывается в 3-5 таблиц в MySQL. Честно говоря, меня такой результат удивил, поэтому решил поделиться с хабрасообществом описанием архитектуры этого приложения. Подобный подход применим от баннерных показов до чатов и микроблогов, надеюсь кому-нибудь покажется интересным.

              Во-первых, это приложение однопоточное. Всё делается одним процессом, работа с сокетами — неблокирующими epoll/select, никаких ожидающих ввода/вывода потоков (threads). С развитием HTTP, сначала появлением Keep-Alive, затем AJAX и набирающим популярность COMET, количество постоянных соединений с веб-сервером растёт, на нагруженных проектах измеряется тысячами и даже десятками тысяч, и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.

              Второй ключевой момент — что один SELECT… WHERE pk in (k1, k2, ..., kN) выполняется быстрее, чем несколько SELECT… WHERE pk=… Выполняя работу с базой данных большими пачками можно уменьшить не только число запросов в секунду, но и общую нагрузку.
              Читать дальше →