【问题标题】:how can i manage connections in Indy ? (Delphi)我如何管理 Indy 中的连接? (德尔福)
【发布时间】:2010-07-02 11:01:52
【问题描述】:

我正在使用 indy 10(阻塞模式)编写一个简单的客户端/服务器聊天程序,并且有一个问题是如何管理连接? 例如假设一个用户在服务器上在线,我们必须为将来的请求建立一个连接隧道。换句话说,当用户在线时,服务器不应该需要用户名和密码来处理未来的用户请求。这将与我们在用户到来时创建的隧道有关。

我们如何管理连接?

[对不起我的英语不好]如果你听不懂我请告诉我再发一个新帖子。

谢谢

【问题讨论】:

    标签: delphi connection indy


    【解决方案1】:

    对于问题中描述的场景,没有太多的管理 要做。为避免必须对每个请求重新进行身份验证,只需不要关闭连接。特别是在聊天服务器中,很可能每个参与者都会建立一个连接,然后在聊天期间继续使用相同的连接。

    Indy 服务器对象已经保存了它们打开的连接列表,因此当您想向其他参与者广播聊天消息时,只需遍历该列表即可。

    【讨论】:

    • 同意。如果您需要在请求之间保留自定义数据,例如身份验证详细信息,您可以将每个连接的信息存储在 TIdPeerThread.Data(Indy 9 和更早版本)和 TIdContext.Data (Indy 10) 属性中。只要连接保持打开状态,每个客户端只需收集和存储一次该信息。如果客户端在请求之间断开并重新连接(例如在 HTTP 中),那么您必须手动跟踪来自一个连接的信息并将其应用于下一个连接。
    • 谢谢!好答案 。最后,您为我提供了哪种方式以最少的处理来管理连接和会话 ID?我认为我们必须将当前的 Acontext-Index 作为会话 ID 发送给客户端,并且在将来收到会话 ID 时的请求中,我们将从其中提取 Acontext(connection) 索引并继续与此隧道通信。不是吗?
    • 不,克米亚。一旦连接关闭,上下文对象就会被销毁。既然您已经接受了这个答案,那么本身就不需要会话了。相反,连接就是会话。服务器不需要告诉客户端任何事情,因为只要客户端保持打开的连接,它就已经拥有了它需要的一切。服务器还会继续了解连接,因此在您的 Indy 事件处理程序中,无论事件发生在什么连接上,您都将自动获得正确的上下文对象。
    【解决方案2】:

    我认为每秒 100000 次检查将比拥有 10000 个持久 TCP 连接消耗更少的资源。无论如何,您将需要以某种方式处理这 100000 条命令,因此这些检查不会成为瓶颈。

    尝试改用 UDP 消息。例如,大多数 MMO 游戏同时使用 TCP 和 UDP 连接。 TCP 仅用于关键数据,UDP 用于任何其他数据。在您的情况下,UDP 似乎是可以接受的。客户端可以发送带有一些自动增量 ID 的 UDP 数据包,服务器可以定期发回它没有收到的 ID 列表,因此客户端可以重新发送它们。

    【讨论】:

      【解决方案3】:

      如果客户端登录,一个选项是在服务器端创建一个唯一的会话 ID(或“令牌”),例如 GUID。并且在每个请求中,客户端都包含此令牌。

      服务器会维护一个客户端会话和相关会话数据的列表,并在该列表中查找令牌。

      即使客户端暂时与 Internet 断开连接但仍知道其令牌,应用程序仍可以重新连接并继续与服务器的会话。

      【讨论】:

      • 感谢您的回复,但想象一下,有 10,000 个在线用户,每个用户每秒向服务器发送 10 条消息。所以最终我们将在一秒钟内检查 100,000 个会话 ID。这对服务器来说是致命的!
      • 当我阅读“一个简单的聊天程序”时,我没想到有 10,000 个用户每 100 毫秒发送一条消息 :)
      • 哦,你说得对:D。但是如果我们想将这种方式用于更大的项目呢?是否可以 ?或者你提供另一种方式?谢谢你 mjustin :)
      • 不适用于 Delphi,抱歉。或许APE(免费的Ajax Push Engine,Sourceforge项目名称Ajax Chat Engine),可以处理10万以上的用户,是一个选择:@ 987654321@ - 服务器是用 C 编写的
      猜你喜欢
      • 1970-01-01
      • 2011-01-31
      • 2015-07-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-07-08
      • 1970-01-01
      相关资源
      最近更新 更多