im-протокол

а в xmpp страшно смотреть.

Это почему еще?

или хотя бы compatible

Любой tcp протокол «compatible»... Если тебя xmpp не устраивает ибо «страшно смотреть», свелосипедь за 5 минут на коленке. Делов то... Или тебя tcp пугает?

xmpp страшно смотреть

библиотеки сделают работу за тебя

psyc, silc. Оба не нужны, впрочем.

Что такое каноническая opensource реализация не знаю, но один из самых простых протоколов - IRC.

IRC

Для высокоуровневых языков (ruby, python) есть очень удобные обвязки для xmpp.

Много на хабре про джаббер написано, например:
http://habrahabr.ru/post/151464/
http://habrahabr.ru/post/119567/

Это почему еще?

в xmpp, как мне кажется, слишком много мусора. это весьма субъективный параметр. ростер на все случаи жизни, транспорты в любые сети, минимум два ХЕРа на передачу файлов, приоритеты ресурсов, которые клиенты по разному трактуют и т.п.

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

Любой tcp протокол «compatible»... Если тебя xmpp не устраивает ибо «страшно смотреть», свелосипедь за 5 минут на коленке. Делов то... Или тебя tcp пугает?

o_O

в оригинальном посте было неправильно написано. речь идет о openssl-compatible реализации, а не протоколе.

перед тем, как велосипедить, надо понять, что уже есть запиленное.

а что касается делов, то чтобы сделать годно надо много труда вложить.

psyc, silc. Оба не нужны, впрочем.

спасибо. они, действительно не очень подходят.

Что такое каноническая opensource реализация не знаю, но один из самых простых протоколов - IRC.

Да, IRC — отличная штука, но он, боюсь, слишком прост.

То, каким я его знаю, pki там сложно реализуем.

Для высокоуровневых языков (ruby, python) есть очень удобные обвязки для xmpp.

Ну да. На одном форуме мне рассказывали, что utf-8 — отличная штука для обработки строк. На вопрос о переменной длине символа был простой ответ: у тебя же есть c++, там есть методы. Сделай себе метод nextChar() и все у тебя будет хорошо и просто.

Я это к тому, что все эти валенки будут торчать в виде использованного трафика, памяти и cpu.

Надеюсь они там хотя бы сжимают свои xml-ки перед тем, как отправлять и уж тем более шифровать.

На вопрос о переменной длине символа был простой ответ: у тебя же есть c++, там есть методы.

1. UTF-8 — идеальная кодировка для передачи текста. Она не требует BOM, в ней средний текст весит меньше. Реально хочешь много работать с текстом после получения — сделаешь iconv() или велосипед utf8->utf32 (который тривиален).

2. Если под символом понимать знакоместо, то 100% кодировок юникода имеют переменную длину. С нетривиальным алгоритмом поиска этой длины. Если минимальную единицу, по которой можно резать строку — в общем-то, ничего не меняется, юникод по-прежнему переменной длины. Грепать в юникодном тексте опять же нетривиально (я не про gnu grep, который работает со строкой байтов вместо текста) независимо от кодировки.

xmpp использует передачу в формате xml.
это избыточный протокол по двум причинам:
1) команды передаются в виде текста
2) команды удвоенны (<teg> парам-пам-пам </teg>)
3) данные передаются в base64 (на 33% больше байт)

С учетом всего этого, протокол сильно раздутый.

irc протокол plain-текстовый. Т.е. нет скобок, команды не дублируются, текст не кодируется.

Если же хочешь сильно экономить трафик, то пили свой бинарный протокол.

Во всех случаях при использовании шифрования трафик раздуется за счет более длинного приветствия и того, что шифротекст требует большего объема.

На одном форуме мне рассказывали, что utf-8 — отличная штука для обработки строк

UTF-8 — идеальная кодировка для передачи текста.

Этсамое. Я понимаю, что передача это в каком-то смысле обработка, но, думаю, из текста было ясно, что речь идет скорее о работе типа поиска подстрок, например.

Если под символом понимать знакоместо, то 100% кодировок юникода имеют переменную длину

Мне казалось, что utf32 имеет 4 байта и это пока предел. я не прав? а есть там подмножество где непротяженные знаки запрещены?

Мне казалось, что utf32 имеет 4 байта и это пока предел. я не прав?

Так тебе же всё равно обрабатывать комбинирующие символы, среди которых есть весьма милые вещи. И RTL/LTR отделять от слова достаточно весело.

а есть там подмножество где непротяженные знаки запрещены?

ASCII где-то в восьмидесятых годах прошлого века.

Кодировки юникода, в которой одна графема == один codepoint с заранее известным размером, нет и не будет, он развивается в противоположную сторону (разбиваются все прекомбинированные символы, поскольку соединять их — работа софта).

речь идет о openssl-compatible реализации, а не протоколе

а что это вообще? Протокол мессенджера он как бы на другом уровне работает, ему пофиг должно быть, поверх TCP он работает или поверх SSL/TLS которые работают поверх TCP

Кодировки юникода, в которой одна графема == один codepoint с заранее известным размером, нет и не будет, он развивается в противоположную сторону (разбиваются все прекомбинированные символы, поскольку соединять их — работа софта).

Я не знаю, куда он там развивается, но для той же «й» допустимо как указание самой «й», так и («и» + «краткий»). Я за этим делом слежу сбоку, поэтому допускаю, что второй способ можно просто запретить на уровне договоренности в рамках обработки внутри приложения.

Запрети арабам или индусам, у которых нет вариантов в половине случаев. Ну или юзай CP1251.

а что это вообще? Протокол мессенджера он как бы на другом уровне работает, ему пофиг должно быть, поверх TCP он работает или поверх SSL/TLS которые работают поверх TCP

что это? реализация? ну, это когда код надо писать. т.е. это надо взять редактор, написать код, скомпилировать его и проверить, что все работает как надо. слова «совместимая с openssl реализация» означают, что не придется всю сетевую часть переписывать, чтобы заставить код работать через openssl.

это вообще раздел development ?

ICQ!

что не придется всю сетевую часть переписывать, чтобы заставить код работать через openssl.

что там переписывать, заменяешь везде recv() на SSL_read(), а send() на SSL_write(), ну и создание сеанса имплементируешь, и все :)

Ничего не переписываешь, запускаешь через stunnel, всё работает. Это раздел development, а что ты тут делаешь?

Ничего не переписываешь, запускаешь через stunnel, всё работает.

Ну-ну, разработчег. Вроде ясно написано, что речь про openssl.

stunnel заворачивает TCP через openssl прозрачно для приложения. Проблемы?

что там переписывать, заменяешь везде recv() на SSL_read(), а send() на SSL_write(), ну и создание сеанса имплементируешь, и все :)

Ну да. Это если в самой реализации все просто =( Ведь есть же любители понаписать на плюсах с qt.

stunnel заворачивает TCP через openssl прозрачно для приложения. Проблемы?

Э-э-э... никаких. Кроме той, что это костыль для протоколов, которые не умеют по другому. Всерьез говорить о намерении заставлять пользователей протокола использовать такой враппер это довольно странно. Есть случаи, когда это наилучшее решение, но в оригинальном сообщении, на мой взгляд, достаточно информации, чтобы понять, что это не тот случай.

Ок, ты не понимаешь смысла разделения уровней (да хоть OSI), о котором тебе говорят тут весь трэд. Сравнительно тривиально ssl включается без правки оригинального кода. Совсем тривиально правкой.

Хотя в некоторых случаях «просто включить SSL» не настолько тривиально. Например, xephyr использует kerberos-авторизацию, UDP на транспортном уровне, разворачивается внутри универов и ssl там тупо не нужно.

перед тем, как велосипедить, надо понять, что уже есть запиленное.

Джаббер, годный. Есть реализованные серверы, а не только либы.

то чтобы сделать годно надо много труда вложить.

Ой да ладно, не забудь юникод изначально предусмотреть и это уже полдела. Что там в im протоколе может быть сложного?

Ок, ты не понимаешь смысла разделения уровней (да хоть OSI), о котором тебе говорят тут весь трэд. Сравнительно тривиально ssl включается без правки оригинального кода. Совсем тривиально правкой.

Ну да. Чувствуется бездонное понимание теории и богатый опыт за плечами. Вы, вероятно, студент-старшекурсник?

Что там в im протоколе может быть сложного?

гарантированная доставка группе пользователей при наличии нескольких серверов, и без дублей.

Джаббер, годный. Есть реализованные серверы, а не только либы.

Он дико популярен и либ действительно много. К сожалению, вменяемых клиентов мало. А вот нормальный сервер, когда я ставил в последний раз был только один на erlang: ejabberd. Это было давно, но он был какой-то мутный, и во многом это из-за протокола.

Что там в im протоколе может быть сложного?

Ну, я могу озвучить примерный список...

• синхронизация сообщений между разными клиентами одного аккаунта (прочитанное/непрочитанное тоже),
• гарантированная доставка сообщений посланных в оффлайн,
• гарантированная передача файлов через двойной нат (можно с сервером, но без супернодов),
• небольшой встроенный pki на уровне pgp, для шифрования/подписи,
• п.3. нужно дружить с AD и аналогами,
• конференции (тут, на мой вкус, джаббер хорош),
• текст + аудио + видео, в т.ч. в конференциях,
• совместить это все с телефоном, хотя бы на уровне СМС, а лучше и звонки тоже.

Последние пункты, это скорее уже мечты. В одиночку такое, думаю, не осилить за «досуговое время».

icq это не протокол

http://xmpp.org/extensions/xep-0065.html

RFC 1459, 2810, 2811, 2812, 2813 aka IRC

Во всех случаях при использовании шифрования трафик раздуется за счет более длинного приветствия и того, что шифротекст требует большего объема.

Прямо - не требует. Если задача состоит в шифровании, то текст сжимается перед зашифрованием с целью избавиться от избыточности, потом шифруется сессионным ключом, который был сгенерирован при установке соединения - результат сравним по размеру с оригинальным текстом.

А косвенно - да, потребует. Потому что зная, что первое сообщение в сессии будет скорее всего «Hi!», «Привет» или «Превед», криптоаналитик в режиме реального времени извлечёт твой ключ сессии и все остальные сообщения в ней. Поэтому надо как-то досыпать рандомных данных в передаваемые сообщения, чтобы они были менее предсказуемы и просто тупо больше.

Он дико популярен и либ действительно много. К сожалению, вменяемых клиентов мало. А вот нормальный сервер, когда я ставил в последний раз был только один на erlang: ejabberd. Это было давно, но он был какой-то мутный, и во многом это из-за протокола.

Короче личная неприязнь )))

Ну, я могу озвучить примерный список...
а в xmpp страшно смотреть

Не ну а ты как хотел?! Сам просишь во все поля джаббер, но дайте мне не джаббер... thread/0

но он, боюсь, слишком прост

Тогда используй XMPP там иксэмэли и он достаточно huge'n'bloated. И обязательно используй JAVA и C++ c BOOST!
/фрустрация
---

То, каким я его знаю, pki там сложно реализуем.

См. SILC, там с этим лучше должно быть.

Не ну а ты как хотел?! Сам просишь во все поля джаббер, но дайте мне не джаббер... thread/0

Не, я хочу не джаббер. Как писал quantum-troll:

Тогда используй XMPP там иксэмэли и он достаточно huge'n'bloated

и тут я с ним согласен. Именно этим xmpp меня и раздражает. мне нужен джаббер без мусора.

Буду внимательней смотреть SILC. Спасибо quantum-troll и x3al.

А тред, действительно, пора закрывать.

Не, я хочу не джаббер.

Нет, в реквесте ты описал джаббер, но зачем-то трахаешь всем мозги.

и тут я с ним согласен. Именно этим xmpp меня и раздражает. мне нужен джаббер без мусора.

Тебе xml-ки вместо мессаг читать?! Да тебе даже код писать для работы с ними не нужно! Просто у тебя из-за идиотских комплексов боязнь xml на ровном месте...

Буду внимательней смотреть SILC. Спасибо quantum-troll и x3al.

Успехов тебе с этой маргинальной поделкой...

Тебе xml-ки вместо мессаг читать?! Да тебе даже код писать для работы с ними не нужно! Просто у тебя из-за идиотских комплексов боязнь xml на ровном месте...

Ну окай. Я смотрю свой список и пункт номер 1. XEP-0280 или его какой-нибудь аналог реализован в каких-нибудь либах/серверах/клиентах ?

Пока я слышал, что гугл насильно рассылает сообщения на все ресурсы...

А что-нибудь для поддержки пользовательских сертификатов, где сервер как УЦ? большая часть XEPов отложена.

Или мне нужно велосипедить новый протокол поверх джаббера, который будет шифровать все перед отсылкой? чтоб, как в некоторых джаббер-клиентах, была галочка «хочу, чтоб разговор шифровался» ? возникает вопрос нахрена тогда xml, если я ему буду закодированные байты давать? ерунда какая-то.

зато мои комплексы опять разоблачили.