crossoverJie

> 1. 按照map缓存channel的思路，我用测试工具发起了几百个连接然后断开，发现map的size会大于实际的有效channel个数，这个问题如何解决。 这个数量理论上是一致的，但出现网络抖动导致 `channelInactive` 函数无法触发就可能会导致大于实际数量。 但其实服务端也有心跳检测机制，超过一段时间没有上报心跳的客户端会被踢初，所以这个数据是最终一致的。 > 1. 2.请问源码里面有消息限流功能吗，针对全局消息速率限流，针对单个channel消息速率限流。想尽量以服务端稳定为主。感谢 暂不支持，后续会考虑加入。

1. 使用的是 `ConcurrentHashMap` 存放的 `Channel`，不会出现并发问题。 2. 是否踢出新接入的客户端不应该由 `Server` 来做，直接放到路由层就可以，比如可以利用 `Redis` 记录各个节点的在线数，`route` 在分配 `Server` 的时候优先将较少的连接的服务端分配出去，已经达到上限的就直接剔除，这也是权重分配的模式。

> 对于客户端来说,相互间的通信都是基于socket的,它不应该关注消息转发的逻辑. 这个我不太同意；客户端之间如果互相单独通信，那平台就没有意义了；比如微信不可能让你我单独私聊吧，所有消息都得经过平台，不然从业务上讲就没啥意义。 再从技术上讲，我们两个私聊的外网 IP 谁出？带宽之类的服务也是要钱的，必然得需要一个统一的服务器。 > 1.在这点上消息发送上不统一,职责也不太清晰. 客户端的职责仅只有发消息和收消息，不太清楚你说的职责不清晰是指他有了什么额外的职责。 > 2.如果将来改成真正的点对点通信,类似于局域网内部传输,这种转发模式很致命 真正的局域网点对点通信一般都是老师课堂教的 `demo`，没什么太大参考性。 > 3.客户端模块应该是独立的,毕竟应该是两个人之间通信(转发是内部逻辑,不应该暴露给客户端). 对于客户端来说只是一个消息发送的 `http` 接口而已，它并不清楚什么路由层是怎么处理的。 > 可以考虑客户端发送给socket服务器,收到后socket返回ack,由socket服务器向中控服务器发送转发请求,中控服务器收到后,发到处理队列,并发轮训处理队列,存储消息,查询转发服务器转发,或存入离线服务中. 这条不就和你说的点对点通信冲突了嘛，自然是需要一个服务器的；不过你说的由服务端转发我觉得才是职责不单一了，服务端应该只管接收消息然后推送消息，至于转发的事情交给 `route` 来做，这样一个是 `route` 可以水平扩展，服务端的职责也很单一。 `任何架构都可以新增一层来解决问题`我觉得非常有道理。

@hxlzpnyist 👍

这是后续优化的方向，比如每次的 `TCP` 报文都会携带一个 `session` 或者是 `token` 做校验。

> io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: no further information: /172.17.48.1:11211 本地的这个服务连不上：` 172.17.48.1:11211`,是不是没有启动。

> 我也是一样的问题，部署到阿里云的时候 客户端连接超时。 @rainbowyao 可以看看注册到 ZK 里的服务地址是多少，多网卡加上内网环境可能会出现注册了内网地址的问题。

> [2020-03-29 10:03:13] zhangsan$ 登录信息不匹配！ @jdkYang 我 demo 里配置的 `zhangsan` 这个用户得在你自己的服务中注册才行，详情请看这里： https://github.com/crossoverJie/cim#%E6%B3%A8%E5%86%8C%E8%B4%A6%E5%8F%B7

duplicate #65

@yuriolisa Is this the expected outcome of the issue? Current: ```json {"level":"info","ts":"2024-03-12T14:39:02+08:00","msg":"test"} ``` Expect: ```json {"severity":"info","ts":"2024-03-12T14:41:24+08:00","msg":"test"} ```