求助IM群聊里消息的ACK应答的疑问，群聊跟单聊一样逐条应答吗

单聊消息可靠性可以通过ack机制保证。如果发送方没有收到对方的接收确认可以重发。存离线后服务端可以发起接收确认。
可是群聊呢？500人的群需要收到500人的接收确认吗？

没办法，无论是否群聊，对于接收者来说，都是“一条一条”的消息，所以ack是肯定要的，而且跟单聊相比并没有什么不同

引用：JackJiang 发表于 2022-09-27 20:43
没办法，无论是否群聊，对于接收者来说，都是“一条一条”的消息，所以ack是肯定要的，而且跟单聊相比并没 ...

明白，我的意思是，接收方怎么判断是不是所有群成员都收到了？（因为群成员有500个人，我取消重传的逻辑是500个人都给我回接收ack，那么发送方本地是不是维护每条消息的待ack列表？待解答）。改一下逻辑，我们把离线消息在分发之前就存下来，离线消息存成功，服务端直接发一条所有人接收确认成功的ack给发送方可行否？

引用：frfr46467979 发表于 2022-09-28 08:31
明白，我的意思是，接收方怎么判断是不是所有群成员都收到了？（因为群成员有500个人，我取消重传的逻辑 ...

“接收方怎么判断是不是所有群成员都收到了？”：这句怎么理解？
你是想做钉钉里面的已读/未读功能？

引用：JackJiang 发表于 2022-09-28 10:13
“接收方怎么判断是不是所有群成员都收到了？”：这句怎么理解？
你是想做钉钉里面的已读/未读功能？

说错了，是发送方，我意思是，A给500人的群发消息，A怎么界定是不是有没有收到500个人的接收ack？
群成员是动态的

引用：frfr46467979 发表于 2022-09-28 10:39
说错了，是发送方，我意思是，A给500人的群发消息，A怎么界定是不是有没有收到500个人的接收ack？
群成 ...

A只管发给服务端，至于服务端扩散写发出去的群消息有没有收到ACK这不需要发送者关心，由服务端逻辑去处理就好了

引用：JackJiang 发表于 2022-09-28 10:54
A只管发给服务端，至于服务端扩散写发出去的群消息有没有收到ACK这不需要发送者关心，由服务端逻辑去处理 ...

好的，因为单聊的消息我是这样处理的：
A发给B，服务端收到消息后给A发送收到Ack，服务端存离线，判断B是否在线，在线直接投递。不在线服务端给A回复接收Ack。A要收到2个Ack才算发送完成。
因此群聊想套用这个逻辑感觉很复杂。

引用：frfr46467979 发表于 2022-09-28 11:41
好的，因为单聊的消息我是这样处理的：
A发给B，服务端收到消息后给A发送收到Ack，服务端存离线，判断B ...

无论单聊还是群聊，消息都是一条条扩散写发出去的，没什么区别