有关client-id设计的一点想法，应用场景在workerman-chat具体化时，思路来源redis存取聊天记录
有关client-id设计的一点想法，应用场景在workerman-chat具体化时，思路来源redis存取聊天记录。现在client-id有3个参数按规则生成，ip+ port +递增数字。我的想法是有下面的参数生成ip+port +(from,to),(from在具体网站中，谁发的消息——具体表示使用uerid)(to在具体网站中，消息发给谁——具体表示使用uerid)。这个想法也许有问题。但是，具体化时总是感觉现在的client_id的设计不是最有的。看看大家有什么别的思路。
3267 4 0
4个回答
相似问题
年代过于久远，无法发表回答
月贡献榜
赞助商
热门问答
workerman 里面的redis 队列是基于redis的什么特性实现的？
联表一次查询和查询后循环内再查询别的表组装数据，哪个性能好呢？
PHP8.4下webman直接用topthink/think-orm想了解数据库连接该写在哪里
webman想使用人大金仓数据库，如何处理？ 求方案
微信SDK，关于webman里推荐的
redis-queue 延迟任务 可否延迟第二天触发？
127.0.0.1:1238地址显示已被占用?
请问下现阶段是否有必要使用异步mysql查询？
请教：webman如何让错误直接在网页显示，而不是在命令行打印出来？
webman不错，但不建议官方做webman-admin
我的理解client——id必须具备的特征，1地址唯一不重复，2刷新页面，销毁client-id,在重新产生clien_id。我上边的想法，我认为符合条件。大家怎么想
如果可行，必然会砍掉或者废弃几个workerman_chat函数，是具体化的过程更简单一点
workerman中得client_id无法自定义，（此句回复误导了99.99%人）每次客户端连接workerman的那一时刻会生成一个新的全局唯一的clent_id。
GatewayWorker中的client_id确实无法自定义，因为改了就无法通讯了。
没觉得现在的client_id机制有什么问题。
也没看出你的client_id生成方案有什么好处，反而觉得不通用了。
个人看法。