Plugin:Jabber/ru/Передача файлов

From Miranda NG
< Jabber protocol‎ | Jabber protocol
Revision as of 16:26, 5 January 2013 by RMN (talk | contribs) (Новая страница: «{{Languages|ru=Передача файлов по протоколу Jabber|en=File Transfer Over Jabber|de=Dateiübertragung über Jabber}} == Теория == …»)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Теория

В Jabber существует 4 «способа» передачи файлов.

1. IBB (InBand Bytestreams — «внутри потока», XEP'ы 47 + 95/96) — файл передается в основном XML-потоке, как простые сообщения, но со специальным флагом, чтобы клиент принимающей стороны понимал, что это часть файла, а не передаваемый текст. Принцип работы — такой же, как и у плагина FileAsMessage.

Преимущества
  • самый простой и надежный вариант, работающий в 99% случаев (с условием, что оба клиента поддерживают этот вариант передачи)
Недостатки
  • так как в этом случае бинарные данные передаются как текст, данные жмутся в base64, из-за чего трафик увеличится в среднем на 33%
  • самый медленный
  • при передаче файлов возникают проблемы c обменом сообщениями с контактом, с которым происходит файлообмен.

2. Через прокси jabber-сервера (XEP'ы 65 + 95/96) — файл передаётся через прокси на сервере. Это — не обычный socks-прокси, а специально заточенный для передачи файлов джаббер-сервис! Этот способ подойдёт, если нет возможности прямого соединения с контактом (передающий находится за непрозрачным NAT, прокси) и у передающего правильно указан адрес данного сервиса (который может быть как на сервере передающего, так и на других серверах). Работает следующим образом: передающий подсоединяется к этому серверу (через изменённый протокол socks5), запрашивает сервер на инициализацию передачи файла. Сервер выделяет IP или id сессии, после чего передающий отправляет этот адрес принимающему. Принимающий подсоединяется к серверу и передает id. Если id совпадают, инициализируется передача файла.

Преимущества
  • помогает, если отправляющая сторона сидит за непрозрачным NAT или прокси
  • скорость передачи данных выше, чем у IBB
  • отсутствуют недостатки, присущие IBB
Недостатки
  • не все серверы поддерживают эту возможность (хотя иногда встречаются серверы с таким сервисом, открытым для незарегистрированных на этом сервере пользователей)
  • скорость в большинстве случае ниже, чем у DC.

3. Через DC (Direct Connect, прямое соединение, XEP'ы 65 + 95/96) — устанавливается прямое соединение передающего с принимающим.

Преимущества
  • самый быстрый и надёжный способ передачи файлов
Недостатки
  • не работает, если передающий подключен к интернету через непрозрачный NAT или прокси.

4. Через OOB (Out of Band Data, XEP 66) — упрощённо это можно представить так: клиент передающей стороны открывает у себя HTTP-сервер и даёт HTTP-ссылку другому клиенту, тот подключается и скачивает файл. Преимущества и недостатки аналогичны Direct Connect'у.

Практика

200px|thumb|Рис. 1 Теперь рассмотрим возможности использования и настройки для каждого из способов.

Приём файлов

Чтобы принимать файлы способом, отличным от IBB, необходимо снять галку «Разрешать передачу файлов только внутри потока» (Accept only in band incoming filetransfers) в настройках Вашего jabber-аккаунта (рис. 1).

Передача файлов

200px|thumb|Рис. 2 1. IBB. Работает всегда и везде. Единственное условие — клиент принимающего должен поддерживать данный способ передачи файла, ибо многие клиенты его режут. Для использования этого способа нужно снять все 3 галки в настройках джаббера (рис. 2). (Для гиков: Миранда умеет принимать файлы по IBB и с использованием message, и с использованием iq, но посылает только через message.)

200px|thumb|Рис. 3 2. Через прокси jabber-сервера. Узнать, имеет ли Ваш сервер прокси для передачи файлов, и, если имеет, то узнать его адрес, можно следующим образом: зайти в Просмотр служб (Service Discovery) jabber-аккаунта и найти сервис с identity «SOCKS5 Bytestreams» или «Proxy bytestreams» (обычно это proxy.servername.domain, например, для сервера jabber.ru это proxy.jabber.ru). Ставим соответствующую галку в настройках и указываем адрес нашего прокси (рис. 3).

200px|thumb|Рис. 4 200px|thumb|Рис. 5 3. Direct Connect. Для успешной установки прямого соединения необходимо одно из следующих условий:

  • Прямое соединение Вашего компьютера с интернетом (прямой канал от провайдера с «белым» (реальным) IP-адресом)
  • Если у Вас прямой канал от провайдера с «белым» (реальным) IP-адресом, но установлен роутер, то роутер должен быть:
    • а) или с поддержкой и активированным UPnP, а в настройках сети Миранды для jabber-протокола должна стоять галка «Включить перенаправление портов UPnP» (Enable UPnP port mapping)
    • б) или сконфигурирован для приёма на определённый диапазон адресов, совпадающий с настройками сети Миранды для jabber-протокола (рис. 4).

Если Вы подключены к интернету через прозрачный NAT, то нужно в настройках jabber прописать Ваш реальный («белый») IP-адрес (рис. 5).

Если выставлены галки на передаче файлов и через DC, и через proxy, то передача файла пойдет через прокси.

4. OOB. Необходимы те же условия, что и для DC. Миранда сама будет пробовать данный способ, никакой дополнительной настройки не требуется. Но так как приоритет OOB низок, используется он довольно редко.

Информация для продвинутых пользователей

  1. Как происходит выбор способа передачи файлов:
    • Получаем капсы от клиента.
    • Если умеет SI/FT (XEP 95/96), то отправляем список транспортов, через которые мы можем отправить файл. По умолчанию в списке всегда присутствует 47 XEP, если стоят галки директ-коннекта (BsDirect) или прокси (BsProxyManual), то еще дополнительно добавляем в список 65 XEP.
    • Клиент принимает этот список, решает какой транспорт для передачи файла выбрать. Если стоит галка IBB only, то выбирает 47 XEP, если галка не стоит, то выбирает 65 XEP.
    • После выбора получателем 47 XEP'а отправитель высылает файл, при выборе 65 XEP'а отправитель высылает список из одного IP-адреса (только direct-connect) или двух IP-адресов (direct-connect и proxy)
    • Получатель к этим IP коннектится (проверяет, куда удалось) и отправляет выбранный IP отправителю, отправитель передаёт файл.
    • Если же клиент не умеет SI/FT, то проверяем умеет ли OOB (XEP 66), если умеет OOB, то отправляем ссылку и через HTTP у нас забирают файл.
    • Если же не умеет ни SI/FT, ни OOB, то выдается ошибка передачи файла.
  2. Приоритеты (при условии, что в Миранде настроены все 3 пункта в поле File Transfers, наверху — самый приоритетный):
    • IBB (если у принимающего стоит галка IBB only)
    • Proxy
    • DC
    • OOB
    • IBB (только если в настройках Jabber не выставлено ни одной из трех галок в секции File Transfers)
  • Proxy имеет приоритет перед DC в целях приватности.
  • Proxy и DC описаны одним 65-м XEP'ом. Протоколы там очень похожие, разница только в том, что в первом случае идет коннект до прокси, а во втором — до отправителя.
  • SI/FT (XEP'ы 95/96) в теории могут быть реализованы друг без друга, но по сути они идут вместе и существует проверка на их наличие в коде.
  • Проблемы при передаче файлов через IBB обусловлены тем, что все данные отправляются в цикле в общем потоке, но на сервере есть лимит на количество kB/s от клиента. И, так как нет возможности проверить, принялись ли уже данные от клиента, банально забивается очередь. Все сообщения приходят и уходят, но из-за очереди и лимитов это происходит уже после появления окошка о таймауте.