当前位置: 首页 > 知识库问答 >
问题:

Clojure中的可扩展聊天服务器。存在问题和消息到达b/w重新连接

储毅
2023-03-14

我试图在Clojure中构建一个可扩展的聊天服务器。我使用超文本传输协议-kit、compojure和redis pub/sub在不同节点之间进行通信(扇出方法)。服务器将使用webSocket连接b/w客户端-服务器,并回退到长轮询。单个用户可以有多个连接来与浏览器中的每个选项卡中的一个连接聊天,消息应该传递到所有的连接。

因此,基本上,当用户连接时,我将通道存储在原子中,并使用随机uuid作为

{:userid1 [{:socketuuid "random uuid#1 for uerid1" :socket "channel#1 for userid1"}
          {:socketuuid "random uuid#2" :socket "channel#2"}]
:userid2 [{:socketuuid "random uuid#1 for userid2" :socket "channel#1 for userid2}]}

消息被发布到WebSocket和长轮询通道的公共路由,消息结构如下所示

{:from "userid1" :to "userid2" :message "message content"}

服务器为:from和:to用户ID查找atom中的所有通道,并将消息发送到相应用户的连接通道,还通过redis服务器发布消息,其中连接的节点查找存储在自己atom中的通道,并将消息传递给相应用户

所以我遇到的问题是,如何正确地实现存在。基本上,http kit会在通道断开连接时向您发送状态。状态可以是“服务器关闭”或“客户端关闭”,而我可以处理服务器断开连接(客户端将自动重新连接),但当从客户端断开连接时,我遇到了问题,例如,用户导航到另一个页面,几秒钟后就会连接 当客户端断开连接时,如何确定用户已脱机 此外,我还担心长轮询模式下的消息到达b/w重新连接(我的长轮询超时为30秒)。

还请为上述架构建议一个好的存在机制。谢谢。

如果您需要更多信息,请发表评论。谢谢

编辑#1:

你能推荐一个关于在聊天服务器中实现存在的好教程/材料吗,我似乎找不到任何东西。

我当前的解决方案-

共有1个答案

劳星晖
2023-03-14

从客户端来看,这里有两种不同的情况。

  1. 长轮询。我看不出这是一个问题,如果客户端窗口关闭,将不再有轮询。少一个客户端要求数据。
  2. 网络插座。协议中有一个关闭方法。如果实现正确,客户端应该发送通知。请参阅此处:例如,正确关闭WebSocket(HTML5,Javascript)。

这回答了你的问题吗?

 类似资料:
  • 问题内容: 我正在寻求实现某种聊天服务器。我希望它可以扩展。这似乎是一个很大的问题,所以我想我希望答案是方向指针,有点探索性。 最终用户客户端是Web或电话客户端。我认为某种Websocket实现,例如Socket.IO很好。 在服务器端,我希望使用Node.js。我希望该体系结构具有可伸缩性,以使用户数量不受限制(嗯,在一定范围内,预计不会有很大的成功机会,如果是这样,则由更聪明,经验丰富的人来

  • 我正在尝试在我的应用程序中实现Firebase云消息传递,我已经实现了使用此服务的所有设置,但是当我尝试在我的类中扩展时,它给了我错误,它根本找不到它,我甚至不能如图所示: 我已经添加了所需的所有代码:我将此添加到app gradle 这是模块等级: 这是清单代码: 我把谷歌json文件添加到应用程序中。所以如果有人能帮助我

  • 服务器错误信息来自下述源文件: ·错误消息信息列在share/errmsg.txt文件中。“%d”和“%s”分别代表编号和字符串,显示时,它们将被消息值取代。 ·错误值列在share/errmsg.txt文件中,用于生成include/mysqld_error.h和include/mysqld_ername.h MySQL源文件中的定义。 ·SQLSTATE值列在share/errmsg.txt文

  • 主要内容:服务端程序,客户端程序本节将带领大家结合咱们前面所学的知识开发一个聊天的示例程序,它可以在几个用户之间相互广播文本消息。 服务端程序 服务端程序中包含 4 个 goroutine,分别是一个主 goroutine 和广播(broadcaster)goroutine,每一个连接里面又包含一个连接处理(handleConn)goroutine 和一个客户写入(clientwriter)goroutine。 广播器(broa

  • 全部的 我对RabbitMQ在消耗大量消息(例如280000条)时的性能有一个问题。从性能角度来看,它似乎会上下波动。从管理控制台获取的图中所示的图表演示了这一点,其中消费者平均每秒约40条消息,然后跳到每秒约120条消息: 该模式将再次重复,它将再次返回到40,然后再次返回120,依此类推,如果我在1小时后运行相同的测试,则会发生相同的上下效应,但范围可能会有很大差异,例如每秒140到400条消