Bombus - mobile Jabber client (J2ME)

Bombus - mobile Jabber client

Sources: http://bombus-im.org/wiki/bombus/svn

!!! ВНИМАНИЕ !!! Убедительная просьба перед занесением багрепорта ознакомиться с правилами. Правильно оформленный отчёт об ошибке - залог быстрого её исправления. Спасибо!

| Задачи |

FS#414 — File Transfer: SOCKS5 & IBB

Присоединено проекту — Bombus - mobile Jabber client (J2ME)
Открыто zet (zet) - Saturday, 14 October 2006, 13:30 GMT+2
Последние изменения zet (zet) - Friday, 26 December 2008, 19:58 GMT+2
Тип задачи Новая функция
Категория Основные функции
Статус Назначено
Назначено Eugene (EvgS)
ОС Все платформы
Важность Высокая
Приоритет Нормальный
Обнаружено в версии 0.4-devel
Ожидается в версии 0.7-stable
Срок Не решено
Завершённость 80%
Голоса 1
Приватная задача Нет

Подробности

Реализация передачи файлов (File Transfer) на базе спецификаций XEP-0065: SOCKS5 Bytestreams и XEP-0047: In-Band Bytestreams (IBB)

Комментарий от Shiv (Shiv) - Friday, 20 October 2006, 11:34 GMT+2

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

Комментарий от Eugene (EvgS) - Friday, 20 October 2006, 11:51 GMT+2

никак. Bombus будет просто сохранять принятые файлы

Комментарий от Потапов Сергей (Lion) - Monday, 06 November 2006, 15:54 GMT+2

Главное реализовать поддержку proxy в ByteStream и при этом учесть что в его реализации есть бага - он не выплняет stringprep и utf8 кодирование перед подсчетом SHA кода. Для подсчета SHA он берёт jid инитиатора из атрибута from запроса (activate), а жид таргета из параметра activate, следовательно если таргет будет использовать “подготовленный” jid инитиатора для подсчёта SHA то соединения не будет если “подготовленный” jid инитиатора отличается от неподготовленного.

Ситуация усугубляется различным поведеием клиентов: 1)PSI - при подключении использует “подготовленный” jid и считает SHA код используя “подготовленные” jid-ы. 2)Tkabber - при подключении использует неподготовленный jid и при подстете SHA не подготавливает jid-ы. 3)JAJC - при подключении использует неподготовленный jid а при подсчете SHA “неподготовленный” jid инитиатора и “подготовленный” тагрета.

Отсюда мои рекомендации: при подключении использовать “подготовленный” jid, а при подсчете SHA “неподготовленный” инитиатора и “подготовленный” таргета. При этом проблемы возникнут только при получении файла от Tkabbera и только если его jid не будет эквивалентен “подготовленному”.

P.S. Если jid передающего или принимающего содержит не ланинские буквы, то соединение через прокси не будет установлено. В упрощенном понимании “подготовленный” jid - jid не имеющий в node (ник) и domane (имя сервера) букв в верхнем регистре.

Комментарий от Eugene (EvgS) - Monday, 06 November 2006, 16:42 GMT+2

Lion: однако jep-0065 в этом плане вполне однозначен:

The JIDs provided MUST be full JIDs (i.e., <user@host/resource>); furthermore, in order to ensure proper results, the appropriate stringprep profiles (as specified in XMPP Core [9]) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.

Example 14. Target Connects to StreamHost CMD = X’01’ ATYP = X’03’ DST.ADDR = SHA1 Hash of: (SID + Initiator JID + Target JID) DST.PORT = 0

Комментарий от Eugene (EvgS) - Monday, 06 November 2006, 16:45 GMT+2

более того, требование выполнять stringprep существует более двух лет Version 1.5 (2004-06-29) Added requirement to apply stringprep profiles before SHA1 hashing; added reference to RFC 3174. (psa)

Комментарий от Потапов Сергей (Lion) - Tuesday, 07 November 2006, 09:12 GMT+2

Хотя такое требование существует уже два года, но ни один прокси на сегодняшний день его не выполнят и вряд ли ситуация изменится (хотя у ejabberd-а в планах есть создание такого прокси). В этой ситуации лучше подстроиться под прокси чем ждать когда его исправят, тем более свой код можно быстро исправить если появится правильный прокси.

Комментарий от Eugene (EvgS) - Tuesday, 07 November 2006, 09:56 GMT+2

уже есть прокся, правда, публично её ещё не запустили на jabber.ru - при ближайшем рестарте будет обновление

Комментарий от Eugene (EvgS) - Tuesday, 07 November 2006, 11:51 GMT+2

ibb: нет атрибута block-size в open

Комментарий от zet (zet) - Tuesday, 07 November 2006, 13:00 GMT+2

Добавить:

1. отмену передачи файла

2. отмену приёма файла

3. поддержку докачки прерванной сессии приёма/передачи (?)

3. упростить вывод информации об отправителе (jid в виде баллона или в другом варианте)

4. ограничитель размера файлов для приёма/передачи (?)

Комментарий от zet (zet) - Wednesday, 08 November 2006, 13:31 GMT+2

5. удаление прерванной/отменённой закачки

Комментарий от zet (zet) - Wednesday, 08 November 2006, 13:31 GMT+2

to EvgS: или вынести эти 5 пунктов в отдельные задачи ??

Комментарий от zet (zet) - Sunday, 12 November 2006, 12:57 GMT+2

(6.) Вывести в заголовок окна FT (c правой стороны) значок о непрочитанных сообщениях

Комментарий от zet (zet) - Tuesday, 19 June 2007, 10:29 GMT+2
[ы]: кстати, файлтрансферы умеют вообще по ХЕРу поддержку докачки и проверку MD5 файла

Загрузка...