@Tishka17
Tishka17
14 Jul 2014

Думаю, над подтверждением доставки/прочтения в своём велосипеде и, кажется, у меня получается jabber. А как это сделано в других мессенджерах?

Рекомендовано: Santiago26
14 Jul 2014

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

#tlmlv/2 в ответ на /1
14 Jul 2014

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

#tlmlv/3 в ответ на /2
14 Jul 2014

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

#tlmlv/5 в ответ на /3
14 Jul 2014

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

#tlmlv/7 в ответ на /5
14 Jul 2014

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

#tlmlv/9 в ответ на /8
14 Jul 2014

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

#tlmlv/10 в ответ на /9
14 Jul 2014

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

#tlmlv/12 в ответ на /10
14 Jul 2014

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

#tlmlv/11 в ответ на /6
14 Jul 2014

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

#tlmlv/13 в ответ на /11
14 Jul 2014

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

#tlmlv/15 в ответ на /14
14 Jul 2014

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

#tlmlv/17 в ответ на /16
14 Jul 2014

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

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

#tlmlv/18 в ответ на /17
14 Jul 2014

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

#tlmlv/19 в ответ на /18
14 Jul 2014

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

#tlmlv/20 в ответ на /19
14 Jul 2014

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

#tlmlv/21 в ответ на /18
14 Jul 2014

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

#tlmlv/23 в ответ на /22

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.