引用：嘟嘟嘟哒 发表于 2020-12-03 19:11
将client移植到android上，启动报错：java.lang.ClassNotFoundException:java.lang.management.ManagementF ...

你到github上去提交一个Issue：https://github.com/yuanrw/IM

引用：嘟嘟嘟哒 发表于 2020-12-03 19:11
将client移植到android上，启动报错：java.lang.ClassNotFoundException:java.lang.management.ManagementF ...

自问自答，这个问题还有，但是不影响运行，已经能用android连接上服务了

收获很大，感谢楼主分享，如果可以出一套视频讲解教程，收费也愿意支持，一定通知我。

学习了

github上的代码，我跑起来了，然后看了下client和connector的代码。发现作者对消息可靠性这一块没有实现，对于消息的ack仅仅是消息到达服务端/客户端后，直接向客户端/服务端发送了ack，并没有对消息是否真正送达进行队列缓存和确认。
总的来说，功能实现的太简单，不过代码架构设计的不错。

引用：wisdom_t5L00 发表于 2021-04-25 16:02
github上的代码，我跑起来了，然后看了下client和connector的代码。发现作者对消息可靠性这一块没有实现， ...

去看MobileIMSDK  源码吗，这些都有完善的实现：https://github.com/JackJiang2011/MobileIMSDK

真的是超级厉害！~

引用：a835029688 发表于 2021-06-10 15:29
真的是超级厉害！~

嗯呢

学习了，绝对的干货

ACK的含义应该是确认字符吧，作用是表示发来的数据已确认接收无误。
使用场景应该是在Server确认接收到消息后，返回给Client的，即文章中的sent(hello)。
后面的delivered(hello)和read(hello)应该不属于ACK的范畴了，这样命名是不是有点歧义？
我们公司之前开发的IM产品中，是分为「消息」和「通知」两种类型，通知类型里关于消息投递状态的有一个专门的子类型「消息通知」
delivered(hello)对应的是「已转发」通知，read(hello)对于的是「已读」通知，对应的功能和步骤是一样的，但这样子命名和划分应该比较清晰点吧。

引用：椎锋陷陈 发表于 2021-09-03 10:29
ACK的含义应该是确认字符吧，作用是表示发来的数据已确认接收无误。
使用场景应该是在Server确认接收到消 ...

im这种东西不标准，大家做的方案可能都不一样，但最终结果达到了就行了

可靠性-不丢消息那里，ACK确认不应该是发生在发送方和接收方之间的吧？应该是由服务端来充当二者的中间角色。
发送方发送消息到服务端，服务端返回ACK表示已确认接收；
服务端进行消息转发，如果接收方在线并收到消息，成功存储后返回ACK表示已确认接收；

使用lastId来保证消息不重复、不乱序这种方式可行吗？
一种情况是消息乱序到达时，后面的多个消息都必须等待前面的消息到达，不会造成消息显示延迟吗？
另一种情况是如果前面的消息丢失了的话，那后面的消息岂不是永远都无法处理了？

引用：椎锋陷陈 发表于 2021-09-03 10:50
可靠性-不丢消息那里，ACK确认不应该是发生在发送方和接收方之间的吧？应该是由服务端来充当二者的中间角色 ...

其实你说的跟文章里的都能达到目的，只是各有优劣而已

引用：椎锋陷陈 发表于 2021-09-03 10:54
使用lastId来保证消息不重复、不乱序这种方式可行吗？
一种情况是消息乱序到达时，后面的多个消息都必须等 ...

乱序这个问题，在服务端高并发的前提下，是很难在服务端避免的，只能客户端辅助处理，没有百分百顺序的方案，如果有，那就一定有性能损失

引用：JackJiang 发表于 2021-09-03 11:06
乱序这个问题，在服务端高并发的前提下，是很难在服务端避免的，只能客户端辅助处理，没有百分百顺序的方 ...

嗯，服务端面临的情况我能理解，我主要是从客户端接受处理的角度提问的，对于消息乱序到达的问题，客户端可以用时间戳或者向量时钟去重新排序，
只是对于文章中提到的等待乱序的消息到达后再统一处理的做法存疑而已。

个人感觉transfer就是一个败笔，使用结点互联更好。理由：如果有n个connector，并且每台connector所连接的客户端每秒产生x条消息，则每台connector都需要将(n-1)x/n条消息交给transfer去转发，则每秒transfer需要转发(n-1)x条消息，注意到整个系统所有的客户端每秒才会产生nx条消息。所以transfer不仅会有单点故障问题，还会是整个系统的瓶颈。而使用结点互联则没有这两个问题。

引用：qingyun 发表于 2021-09-26 19:49
个人感觉transfer就是一个败笔，使用结点互联更好。理由：如果有n个connector，并且每台connector所连接的 ...

这也是为什么说多数人写的im集群是个假集群，道理就是这样的。看起来可以多实例部署了，但多实例之间的传递中心明明就是单点。。。

引用：JackJiang 发表于 2021-09-26 21:43
这也是为什么说多数人写的im集群是个假集群，道理就是这样的。看起来可以多实例部署了，但多实例之间的传 ...

那应该怎么设计才能做到真正的集群效果，从而部署多个实例，可以给个思路吗。

非常不错，赞