我们目前正在为现有系统开发 API。
它基本上将一些网络请求包装为一个易于使用的库,第三方公司应该能够与我们的产品一起使用。
作为 API 的一部分,有一个事件机制,服务器可以通过持续运行的套接字连接回调客户端。
为了最大限度地减少服务器上的负载,我们希望每台计算机只有一个连接。目前,每个进程都有一个打开的套接字,如果您有多个使用该 API 的应用程序,这最终可能会导致负载问题。
所以我的问题是:如果我们想将 API 部署为单个独立程序集,解决问题的最佳方法是什么?
我们想到的几个选择:
这些看起来都不理想。
还有更好的想法吗?
您的意思是类似Net.TCP端口共享吗?
您可以在打开套接字时修复客户端端口,例如 45534。由于一个端口只能由一个进程打开,因此一次只有一个进程能够打开与服务器的套接字连接。
嗯,有很多方法可以解决这个问题,正如所有答案和评论中所表达的那样,但您可以使用的更简单的方法可能是将全局状态存储放在当前计算机的所有用户都可以访问的位置(可能是您)可能有不同的用户登录到您存储的计算机上,谁有权打开它。就像过去所说的“锁”一样。该存储可以是本地或 Intranet 数据库中的字段、简单文件或其他任何内容。这样您就不需要构建或分发额外的二进制文件。
当客户端连接到您的服务器时,您将创建一个新线程来处理他(而不是进程)。您可以将他的 IP 地址存储在静态字典中(在所有线程之间共享)。 比如:
static Dictionary<string, TcpClient> clients = new Dictionary<string, TcpClient>();
//This method is executed in a thread
void ProcessRequest(TcpClient client)
{
string ip = null;
//TODO: get client IP address
lock (clients)
{
...
if (clients.ContainsKey(ip))
{
//TODO: Deny connection
return;
}
else
{
clients.Add(ip, client);
}
}
//TODO: Answer the client
}
//TODO: Delete client from list on disconnection
我们提出的最佳解决方案是创建一个 Windows 服务,该服务打开一个命名管道,通过一个到服务器的套接字连接来管理多个客户端进程。
然后我们的 API 将能够检测服务是否正在运行/安装,并回退到为客户端创建自己的连接。
第三方可以决定是否要将服务与其产品捆绑在一起,但我们系统中的核心应用程序将安装它。
如果没有人有更好的选择,我会在几天内将此标记为答案。我希望有一种方法可以将我们的装配作为一个新的过程来执行,但是所有的方法似乎都不是很可靠。