chat one to one как реализовать доставлено и прочитано?

Как это лучше сделать?

Посмотреть описание открытых протоколов, например https://xmpp.org/extensions/xep-0184.html#intro

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

и прочитано

Сделай через веб сокет, сигнал о прочтении шли в него же

список ids всех полученных сообщений

Или передавать одну дату. Сообщения ведь обычно по дате сортируются и читаются в том же порядке. Но это при условии, что твой клиент не будет прокручивать до самого последнего сообщения автоматически.

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

Сервер-то формирует данные, но коим образом он может знать, что данные клиент забрал?

В моем понимании клиент может точно знать, например при post, что данные сервер получил и обработал(сервер вернет статус код), а сервер откуда знает, долетели до клиента данные или нет?

А веб сокет не накладно по ресурсам? Все же клиенты поддерживают соединения с сервером, т.е подсаживаются на вебсокет. Не поплохеет инстансу, если на нём будут висеть 1000-10000 соединений?

Для данной задачи - это оверхед. Как использование rocketchat, так и использование xmpp

даже в этом случае отсылать обратно все id это излишне. Достаточно послать обратно условный флажок «получил». В респонзе зафигачиваешь request_id, и пускай клиент его шлет, а ты уже маркируешь отосланные данные как полученые. Но вообще, товарищи выше абсолютно правы на счет websocket - его как раз для таких вот вещей и придумывали

Достаточно послать обратно условный флажок «получил». В респонзе зафигачиваешь request_id, и пускай клиент его шлет, а ты уже маркируешь отосланные данные как полученые.

Бррр, ничего не понял. Можешь детализировать?

Но вообще, товарищи выше абсолютно правы на счет websocket - его как раз для таких вот вещей и придумывали

Последний раз, когда я пытался использовать django-channels - у меня это всё восторга не вызвало

если клиент говорит серверу: «дай мне сообщения», - это может значить, что они до него «долетели»?

Это может значить, только то, что он их хочет забрать. Как сервер узнает, что сообщения клиент забрал?

ответить с фронта "OK", не? ну или куда они там придут.

а если это какой нибудь веб чат, то зачем там вообще серверу знать, что клиент забрал сообщения?

1. Это не веб-чат, а мобильная аплекуха
2. Ответить «ОК». Расскажи свою реализацию этого

как клиент узнает, что для него есть новое сообщение? ему должно придти уведомление? вот например сразу после получения уведомления, можно и сказать «ОК»

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

потому как не вижу механизма, при котором сервер может узнать о том, доставлены ли данные клиенту или нет

после получения отдавать список ids всех полученных сообщений

Сам же ответил, ещё в ОП.

так и использование xmpp

Никто не заставляет использовать что-то. Просто, можно посмотреть, как это реализовано в открытых протоколах, в том числе и xmpp, XEP-0184 нам рассказывает о «квитанциях».

В телеге, тоже самое, квитанции.

надо смотреть как реализовано получение сообщений.

клиент подключается и спрашивает «есть новые сообщения?» > сервер отвечает есть или нет. > если сообщения есть, то клиент говорит «дай их сюда и пометь как доставлено». и не важно читал он их или нет. достаточно того, что был запрос на новые сообщения.

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

Правильно отметили. Можно сделать на уровне транспорта:

• если long polling, то сам факт забора сообщений с сервера - это «получено клиентом» (одна галочка)
• если хуки, то ответ клиента 200 на апдейт - факт доставки сообщения.

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

а зачем слать id обратно?

есть 3 состояния у сообщения: «новое», «доставлено», «прочитано».

в базу говоришь «дай все новые». и помечаешь их «доставленными». заходишь в чат и говоришь «пометь все доставленные как прочитанные»

а зачем слать id обратно?

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

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

А если на него будет 1000-10000 http запросов сваливаться — лучше будет?
Ты же не написал ничего про характер нагрузки.
Вот сам и решай.

Дизайнить свой протокол это тоже оверхед :). Но rocketchat / xmpp тут конечно не в тему.

https://djangopackages.org/grids/g/chat/