Разработчики Popcorn Time планируют уходить в i2p

    image

    Один из самых активных форков проекта Popcorn Time, popcorn-time.se, задумался о переходе в сеть i2p. Летом прошлого года проект, заботясь об анонимности своих пользователей, проект начал предоставлять им бесплатный VPN, встроенный в приложение. Однако, к настоящему времени возможности провайдера VPN уже исчерпаны из-за большой популярности проекта.

    Как прокомментировала команда проекта текущее его состояние: «База пользователей выросла так быстро, и продолжает расти, что мы не успеваем. Сейчас одновременно пользоваться VPN может лишь незначительная часть наших пользователей. Пока мы делаем первые шаги, и проверяем возможность встроить поддержку i2p».

    Разработчики Popcorn Time рассчитывают при помощи своей объёмной базы пользователей поддержать развитие i2p и таким образом увеличить скорость передачи данных по ней для всех её участников, включая и своих пользователей. Кроме передачи фильмов, планируется распространять обновления программ через сети p2p ввиду уязвимости системы с одним центральным сервером.

    Сеть i2p существует уже более 10 лет, но пока не получила широкого признания публики — такого, как Tor. В отличие от последнего, она не стремится быть анонимизатором для посещения обычных сайтов. Вместо этого сеть нацелена на устройство скрытых сервисов внутри себя. Кроме того, в отличие от Tor, i2p принципиально предназначена для передачи больших объёмов данных. В частности, в сети уже функционирует обмен файлами.

    Popcorn Time — проект, выпустивший приложение, позволяющее бесплатно смотреть фильмы напрямую из торрентов. После недолгого успеха проект был свёрнут из-за претензий со стороны MPAA. Но сразу после этого от проекта отделилось несколько форков.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 20
    • +3
      Могу сказать, что сеть достаточно быстра, а новые ноды в i2p могут только ускорить сеть.
      • +1
        На сколько быстро чем тор? Помню как поставил себе ТОР-брайзер то скорость была 1/10 моего канала.
        • 0
          Гораздо, гораздо медленнее, чем Tor. Максимум видел 2 мегабита/с.
          • 0
            Два мегабита через i2p — это фантастика. Обычно там байты в секунду, ну, максимум, килобайты.
            • 0
              Да нет, вроде, я даже на hiddenbooru.i2p иногда заглядываю, нормально открывается. Байт в секунду никогда не видел, отклик больше 5 секунд тоже редко бывает.

              У меня floodfill-нода с несколькими тысячами подключений, которая запущена круглосуточно. Может быть, в этом и дело.
              • 0
                Откуда столько коннектов?
                У меня 24\7, динамика+noip, ограничение 2Мбит\с в обе стороны, нода транзитная. Показывает совсем скромные статы:

                Активные: 17 / 152
                Быстрые: 29
                Высокоемкие: 74
                интегрированные: 177
                Известные: 242

                Что-то принципиально изменится если дам ей статику?
              • 0
                У Вас слабоинтегрирован в сеть роутер. Или проблема на стороне сайта. Скорости с порядком «байты в секунду» были в i2p года три назад. Год назад, один мой приятель там торренты раздавал на сотнях килобит в секунду.
                • 0
                  Это очень странно, потому что я специально выделенный сервер под это дело поднял и он на ipv4/ipv6 почти 24\7 в онлайне.
        • 0
          планируется ли добавлять фильмы с русскоязычной озвучкой?
          • 0
            Если бы еще I2P был написан на компилируемом языке (как Tor) и не требовал бы Java VM…
            • 0
              • 0
                Только второй развивается и юзабелен, судя по коду и коммитам. Но я говорил о другом — о том, чтобы этот i2pd стал официальным, а не в позиции догоняющего.
                • 0
                  Ну вот когда все функции сети будут реализованы в сишной клиенте тогда и можно говорить об замене официальной версии на сишную (особенно если разработчики основной версии знают си)
                  • 0
                    Такая задача не стоит. i2pd он для тех ниш, где джава не подходит
                    • 0
                      А жаль, тем не менее удачи с его разработкой!
                • 0
                  Какое это имеет значение? Это же деталь реализации.
                  • 0
                    В случае десктопных компьютеров — да. В случае же установки на роутер (или что-то подобное) — java не подойдет. Да и для слабых компьютеров не подходит: проблема не в скорости, а в объеме памяти для работы.
                    • 0
                      Java тут не совсем при делах. На С можно написать программу, которая без гигабайта работать не будет. И на Java можно написать программу, нетребовательную к памяти. Например на любой SIM-карте работает Java-программа, код и память которой умещаются в 64 килобайта памяти. Там, конечно, не совсем та Java, которая на десктопе, но и десктопная/серверная Java не требует сама по себе кучу памяти, если речь не идёт о считанных мегабайтах. Например при запуске java -Xmx16m ей позволяется использовать около 16 мегабайтов оперативной памяти. При этом мой тест показывает, что приложение может выделить на свои нужды около 10 мегабайтов оперативной памяти. Вообще говоря 10 мегабайтов это много и в них можно уместить много функционала.
                      • 0
                        не совсем та Java

                        А точнее совсем не та
                      • 0
                        тут несколько нюансов возникает (где-то с год назад смотрел почему так много cpu выедается):
                        1) шифрование (луковая архитектура заставляет хорошенько погреть воздух, да и памяти кушает порядочно в режиме router именно он)
                        2) SSU (он же udp, очень часто замечал что выступает в приоритете), так как он любит порождать на по потоку на соединение, а отсюда и context switch вылазит и wait на сокетах. NTCP уже nio и от многих проблем избавлен, но он уже tcp.

                        в связке этих 2 пункта дают как неплохое потребление памяти (буфера на чтение-запись, шифрование, стек под каждый новый поток-соединение) и cpu (context switch, постоянное шифрование),

                        так что получаем:
                        1) режем скорость и количество соединений — работаем шустро
                        2) даем много ресурсов — проц захлебывается, поедание памяти и то не настолько заметно даже становится

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое