Tishka17, а почто велосипедишь-то?

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

Tishka17, ну дык, asmack в руки и готово. Или надо поверх готового протокола? xmpp over something не прокатит?

Equidamoid, угу, именно

Equidamoid, подробнее про то, что должен поддерживать something для того, чтобы положить поверх него xmpp

Tishka17, кажется, вот это - альтернативный взгляд от олимпиадников™
https://core.telegram.org/m...g-status-of-messages

я имел в виду тупо пересылать станзы через имеющийся протокол, оно, конечно, костыль, но сработать должно

ох, и тут эта асечка...

Equidamoid, ну он же просил "как это сделано у других клиентов", а выкинуть собственный протокол я его уже давно и безуспешно уговариваю. Для скорейшего решения задачи может быть это и не лучший вариант, фиг знает.

если есть возможность выкинуть, то мб наоборот, его в xmpp обернуть, оно же как раз для подобного создано?
Я тут мечтаю перевести так же одно своё поделие с "хттп-гет раз в 5 секунд", да всё времени нема...

Santiago26, ух. каждый раз когда я открываю протокол telegram, мне хочется заплакать, что я тупой.

Equidamoid, у нас тут регулярно бинарные данные гоняются, xmpp с его base64 нафиг.

Tishka17, ну да, мне тоже. Документация на стандарты XMPP в разы понятнее. Даже на smack (а у него по-моему вообще нет документации).

Santiago26, кратенько можешь объяснить суть?

формат описания параметров почему-то напоминает Objective C.

Tishka17, сейчас, кой-чего дочитаю там

Santiago26, я чет проглядел по диагонали и так не понял, кто кому чего отправляет. Точнее, как подтверждение доходит от одного клиента до другого.

Tishka17, я не понял в итоге, как сообщения отправляются, но кто и какие шлёт понял.
Сервер шлёт клиенту сообщения обычные и сервисные. Кажется, они могут отправляться вместе.
Так или иначе, в них запихивается каждый раз как можно больше полезной информации. Подтверждение получения сообщения ходит в них же. См. Acknoledge of receipt в начале страницы.

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

Santiago26, па повторную доставку кто делает? Сервер или клиент? Или в зависимости от ситуации?

tishka17, не читал, но было бы логично, что если до сервера дошло, а до получателя нет, то сервер. Они ж там трафик экономят

Santiago26, то есть тут подтверждение доставки - не пакет клиент->клиент, а сложная система с перегенерацией ack сервером при получении оной от клиента?

tishka17, похоже, что да

Santiago26, ок, у меня такой вариант был тоже. Третьего видимо не бывает. Теперь надо выбрать какой проще будет реализовать на текущей системе.