Miranda IM Russian Community

В связи с участившимися вопросами про невозможность передачи файлов через Jabber, было решено написать небольшой обзор-мануал о том, как это все работает и как корректно настроить Miranda IM для файлообмена по этому протоколу.

Огромное спасибо:

• Vasilich‘у, как соавтору текста
• mlu, как человеку, цитаты из переписки с которым составляют существенную часть текста
• Ghazan‘у и ъыь, которые ответственно отвечали на кучу, порой глупых, вопросов.

Итак, в Jabber существует 4 “способа” передачи файлов (описания XEP (ксеп) можно почитать на http://xmpp.org/extensions/)

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’у.

---

С теорией закончили. Теперь рассмотрим возможности использования и настройки для каждого из способов.

Первое и немаловажное замечание – чтобы Вы смогли принимать файлы способом, отличным от IBB, необходимо снять галку в настройках Вашего Jabber-аккаунта “Accept only in-band incoming filetransfers”

---

Теперь перейдем к настройкам передающей стороны.

1. IBB. Работает всегда и везде. Единственное условие – клиент принимающего должен поддерживать данный способ передачи файла. Ибо многие клиенты его режут (информация для гиков – Миранда умеет принимать файлы по IBB и с использованием message, и с использованием IQ, но посылает только через message). Для использования этого способа нужно снять все 3 галки в настройках жаббера.

   

2. Через прокси jabber-сервера. Узнать, имеет ли Ваш сервер прокси для передачи файлов, и, если имеет, то узнать его адрес, можно следующим образом: зайти в Service Discovery jabber-аккаунта и найти сервис с identity “SOCKS5 Bytestreams” или “Proxy bytestreams” (обычно это proxy.servername.domain, например, для сервера miranda.im это proxy.miranda.im Ставим соответствующую галку в настройках и указываем адрес нашего прокси.

   

3. Direct Connect. Для успешной установки прямого соединения необходимо одно из следующих условий:
   • Прямое соединение Вашего компьютера с интернетом (прямой канал от провайдера с “белым” (реальным) ip-адресом)
   • Если у Вас прямой канал от провайдера с “белым” (реальным) ip-адресом, но установлен роутер, то роутер должен быть:

   а) или с поддержкой и активированным UPnP, а в настройках сети Миранды для jabber-протокола должна стоять галка “Enable UPnP”
   б) или сконфигурирован для приёма на определённый диапазон адресов, совпадающий с настройками сети Миранды для jabber-протокола

   

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

   

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

4. OOB – необходимы те же условия, что и для DC. Миранда сама будет пробовать данный способ, никакой доп. настройки не требуется. Но, т.к. приоритет OOB низок (см. ниже “информацию для продвинутых пользователей“), он используется довольно-таки редко.

---

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

• о том, как идет выбор способа передачи файлов (big tnx 2 mlu):
  

  Получаем капсы от клиента.

  Если умеет SI/FT (XEP 95/96), то отправляем список транспортов, через которые мы можем отправить файл, по умолчанию всегда в списке присутствует 47 XEP. Если стоят галочки директ-коннекта (BsDirect) или прокси (BsProxyManual), то еще дополнительно добавляем в список 65 XEP.

  Клиент принимает этот список, решает какой транспорт для передачи файла выбрать, если стоит галочка IBB only, то выбирает 47 XEP, если галочка не стоит, то выбирает 65 XEP.

  После выбора получателем 47 XEP‘а отправитель высылает файл, при выборе 65 XEP‘а отправитель высылает список из одного ip-адреса (только direct-connect) или 2-х ip-адресов (direct-connect и proxy)
  Получатель к этим ip коннектится (проверяет, куда удалось) и отправляет выбранный ip отправителю, отправитель передаёт файл.

  Если же клиент не умеет SI/FT, то проверяем умеет ли OOB (XEP 66), если умеет OOB, то отправляем ссылку. и через HTTP у нас забирают файл .

  Если же не умеет ни SI/FT, ни OOB, то выдается ошибка передачи файла.

• Приоритеты (при условии, что в Миранде настроены все 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 от клиента. И, так как нет возможности проверить, принялись ли уже данные от клиента, банально забивается очередь. Все сообщения приходят и уходят, но из-за очереди и лимитов это происходит уже после появления окошка о таймауте.