tcp - 如何为多个消费者重用服务器端 TCP 端点？

Question

我是一个试图了解 TCP 的初学者，我正在使用 Rust。如果我创建一个新的监听器并将其绑定(bind)到一个地址

let tcplistener = TcpListener::bind("127.0.0.1:55555").unwrap();

我可以 tcplistener.accept() 在 127.0.0.1:55555 和客户端上的其他端点之间建立新连接。

在我的例子中，tcplistener 存在于代表插件的结构实例中。每个插件都应该可以从其自己的浏览器选项卡进行控制。每个插件有一个连接(端点对)，一个端点始终为 127.0.0.1:55555。这些插件在具有非阻塞监听器和流的单线程中运行。我使用 websockets，但我不确定这个问题是否特定于 websockets。

我现在做的是

• 实例化插件A
• 接受从浏览器选项卡到插件 A 的第一个连接
• 之后，将插件 A 中的 tcplistener 字段分配给新创建的具有操作系统分配的任意端口的监听器

这似乎可行；如果我之后实例化一个新的插件 B，我可以创建一个绑定(bind)到 127.0.0.1:55555 的监听器并接受连接。如果我不创建具有不同地址/端口的新监听器，则会收到“地址已在使用”错误。

这显然不是一个好的解决方案，因为它无缘无故地占用了所有其他端口。有没有更好的办法？

一条评论说:

Why does each plugin have a TcpListener? Why not have one component with the listener, call accept, then hand off the returned TcpStream to each constructed plugin?

这听起来不错，但是 TcpListener 存储在哪里，它如何传递流？我看到的存储可能性:

• 主持人。我不能修改插件主机，我只是插件作者。
• 一个专用插件。我看到的问题是插件无法访问存储在另一个插件中的任何信息，所以我不知道该怎么做。
• 一个单独运行的进程。我可以想象单独运行一个服务器并让插件成为客户端。用户可以将他们的浏览器连接到服务器，服务器以某种方式代理插件。听起来很合理，但这里的不便之处在于插件用户必须将服务器作为单独的包安装。所以我真的很想避免这种情况。虽然我认为启动服务器可以在插件实例化时自动完成，但也许这就是要走的路？

Answer 1

如果我正确理解您的所有限制，一个解决方法是使用 Option . Option恰好用于“某物或不是某物”的情况。

在这里，你可以有一个 Option<TcpListener> .在新初始化的插件上，这将被设置为 Some(...) , 一旦被接受，将过渡到 None .

这确实有一些缺点:

• 有一段时间没有听众。
• 你必须处理监听器是None的可能性.
• 在第一个插件接受某些内容之前，您不能启动第二个插件。

某种父子关系可能更好，或者如果可能的话，甚至限制为单例插件。