我如何管理 Indy 中的连接？ （德尔福）
我正在使用 indy 10（阻塞模式）编写一个简单的客户端/服务器聊天程序，有一个问题是如何管理连接？ 例如，假设用户在服务器上在线，我们必须为将来的请求建立连接隧道。换句话说，当用户在线时，服务器不应该为将来的用户请求提供用户名和密码。这将与用户到来时我们创建的隧道有关。
我们如何管理连接？
[抱歉我的英语不好]如果你听不懂我的意思，请告诉我再次发送新帖子。
谢谢
i am writing a simple client/server chat program with indy 10 (blocking mode) and there is a question that how can i manage connections ?
for example imagine a user that is online on server , we must make a connection tunnel for future requests . In other words, when a user is online server should not need username and password for future user requests . and it will be do with the tunnel that we created when user has came .
how can we manage connections ?
[sorry for my bad english] if you can't understand me please tell me to send a new post agian .
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于问题中描述的场景，实际上没有太多管理要做。为了避免必须对每个请求重新进行身份验证，只需不要关闭连接。特别是在聊天服务器中，每个参与者很可能会建立一个连接，然后在聊天期间继续使用同一连接。
Indy 服务器对象已经保留了其打开连接的列表，因此当您想要向其他参与者广播聊天消息时，您只需迭代该列表即可。
For the scenario described in the question, there isn't really much management to do. To avoid having to re-authenticate on every request, simply don't close the connection. In a chat server, especially, it's quite likely that each participant will establish a connection and then continue using that same connection for the duration of the chat.
Indy server objects already keep a list of their open connections, so when you want to broadcast a chat message to the other participants, you can just iterate over that list.
我认为每秒 100000 次检查比拥有 10000 个持久 TCP 连接消耗的资源更少。无论如何，您将需要以某种方式处理这 100000 个命令，因此这些检查不会成为瓶颈。
尝试改用 UDP 消息。例如，大多数 MMO 游戏同时使用 TCP 和 UDP 连接。 TCP 仅用于关键数据，UDP 用于任何其他数据。在你的情况下，UDP 似乎是可以接受的。客户端可以发送带有一些自动增量ID的UDP数据包，服务器可以定期发回未收到的ID列表，以便客户端可以重新发送它们。
I think 100000 checks per second will be the less resource consuming thing, than having 10000 persistent TCP connections. And anyway you will need to process somehow these 100000 commands, so those checks would not be the bottleneck.
Try to use the UDP messages instead. For example, most MMO games use both TCP and UDP connections. TCP only for critical data, and UDP for any other data. In your case UDP seems to be acceptable. The client can send UDP packets with some autoincrement IDs, and the server can periodically send back the list of IDs it doesn't receive, so the client can resend them.
一种选择是在服务器端创建一个唯一的会话 ID（或“令牌”），例如客户端登录时的 GUID。并且在每个请求中，客户端都包含此令牌。
服务器将维护客户端会话和关联会话数据的列表，并在此列表中查找令牌。
即使客户端暂时与 Internet 断开连接但仍然知道其令牌，应用程序也可以重新连接并继续与服务器的会话。
One option would be to create a unique session ID (or "token") on the server side, for example a GUID, if a client logs in. And in every request, the client includes this token.
The server would maintain a list of client sessions and associated session data, and looks up the token in this list.
Even if a client is temporary disconnected from the Internet but still knows its token, the application can reconnect and continue the session with the server.