LINUX.ORG.RU

im-протокол


0

1

Всем привет!

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

Желательно, чтобы openssl-only, или хотя бы compatible.



Последнее исправление: ien (всего исправлений: 1)

или хотя бы compatible

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

erfea ★★★★★
()

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

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

vertexua ★★★★★
()

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

m0rph ★★★★★
()
Ответ на: комментарий от tazhate

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

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

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

ien
() автор топика
Ответ на: комментарий от erfea

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

o_O

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

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

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

ien
() автор топика
Ответ на: комментарий от x3al

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

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

ien
() автор топика
Ответ на: комментарий от m0rph

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

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

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

ien
() автор топика
Ответ на: комментарий от Novator

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

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

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

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

ien
() автор топика
Ответ на: комментарий от ien

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

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

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

x3al ★★★★★
()
Ответ на: комментарий от ien

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

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

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

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

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

Novator ★★★★★
()
Ответ на: комментарий от x3al

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

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

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

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

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

ien
() автор топика
Ответ на: комментарий от ien

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

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

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

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

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

x3al ★★★★★
()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от ien

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

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

Harald ★★★★★
()
Ответ на: комментарий от x3al

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

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

ien
() автор топика
Ответ на: комментарий от ien

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

x3al ★★★★★
()
Ответ на: комментарий от Harald

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

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

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

ien
() автор топика
Ответ на: комментарий от ien

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

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

Harald ★★★★★
()
Ответ на: комментарий от ien

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

x3al ★★★★★
()
Ответ на: комментарий от x3al

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

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

ien
() автор топика
Ответ на: комментарий от Harald

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

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

ien
() автор топика
Ответ на: комментарий от x3al

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

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

ien
() автор топика
Ответ на: комментарий от ien

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

x3al ★★★★★
()
Ответ на: комментарий от x3al

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

x3al ★★★★★
()
Ответ на: комментарий от ien

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

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

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

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

erfea ★★★★★
()
Ответ на: комментарий от x3al

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

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

ien
() автор топика
Ответ на: комментарий от erfea

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

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

Deleted
()
Ответ на: комментарий от erfea

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

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

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

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

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

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

ien
() автор топика
Ответ на: комментарий от Novator

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

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

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

anonymous
()
Ответ на: комментарий от ien

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

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

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

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

erfea ★★★★★
()
Ответ на: комментарий от ien

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

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

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

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

quantum-troll ★★★★★
()
Ответ на: комментарий от erfea

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

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

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

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

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

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

ien
() автор топика
Ответ на: комментарий от ien

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

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

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

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

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

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

erfea ★★★★★
()
Ответ на: комментарий от erfea

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

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

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

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

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

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

ien
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.