多个TCP/IP服务器并共享相同的“众所周知的端口” ...不知何故?

发布于 2024-08-13 18:56:04 字数 1002 浏览 6 评论 0原文

我对奇怪的问题措辞表示歉意......这是设计问题:

我正在开发一个服务器(在 Linux 上使用 C++,FWIW),为在消费者 PC 上运行的客户端应用程序的许多实例提供服务。

我想要以下内容:

1)所有客户端首先向“看门人”服务器应用程序表明自己的身份。将此视为一个登录过程,其中传递了用户名和密码等凭据。将网守程序称为“gserver”。 (对于网守。)

2) 每个客户端经过验证后,就会被置于与绑定到同一服务器地址的同一物理服务器盒上运行的不同服务器应用程序的多个实例之一的长期连接中。将这些实例中的任何一个称为“wserver”(“工作”服务器)。

因此,客户端看到的是“看门人”应用程序为其提供了对同一机器上运行的多个“工作”服务器之一的密码访问权限。

这是“真正的”挑战:我们希望专门为入站服务器连接使用“众所周知的”端口号(例如端口 80 或 443)。或者,我们自己的“众所周知的”端口。

我们不希望客户端在与 wserver(n) 的长期连接阶段与服务器上的第二个端口通信。当然,这样做的问题是一次只能将一个服务器进程绑定到相同的端口和服务器地址。

这意味着客户端与 gserver 建立的连接也必须充当长期连接的角色。我认为实现此目的的唯一方法是 gserver 必须在登录后充当代理,并将其自身与客户端之间的流量复制到客户端逻辑上绑定到的特定 wserver(n) 。

如果 client(n) 和 gserver 之间首先建立的 TCP/IP 连接能够以某种方式完整地“传输”到同一服务器上的另一个应用程序,然后由 wserver(n) 实例之一维持,那就太理想了长期连接。

我知道网络服务器会做类似的事情来分散服务器负载。 “负载平衡”。这里的主要区别在于“平衡”是将特定用户分配给特定的 wserver(n) 实例。但我也有这样的印象:负载平衡是一种代理 - 我试图避免这种情况(因为它使架构变得复杂并增加了开销以及单点故障)。

这是一个概念和设计问题。不要担心源代码示例,除非它们对于传达想法是绝对必要的。如果我们确定了一种方法,我就可以对其进行编码。

谢谢!

I apologize for the weird question wording... here's the design problem:

I am developing a server (on Linux using C++, FWIW) that provides a service to many instances of a client application running on consumer PCs.

I want the following:

1) All clients first identify themselves to a "gatekeeper" server application. Consider this a login procedure, with credentials like a user name and password being passed in. Call the gatekeeper program "gserver". (for gatekeeper.)

2) Once each client has been validated, it is then placed into a long term connection with one of several instances of a different server application running on the same physical server box bound to the same server address. Call any of these instances "wserver" (for "working" server.)

So, what the client sees is that a "gatekeeper" application gives it passworded access to one of several "working" servers running on the same box.

Here is the "real" challenge: we want to exclusively use a "well known" port number for the inbound server connections (like port 80 or 443, say.) Or, our own "well known" port.

We would prefer not to have to make the client talk to a second port on the server for the long term connection phase with wserver(n). The problem with this, of course, is that only one server process at a time can be bound to the same port and server address.

This implies that a connection made by the client with gserver must also fill the role of the long term connection. The only way I see to accomplish this is that gserver must, after login, act like a proxy and copy traffic between itself and the client to the particular wserver(n) that the client is bound to logically.

It would be ideal if a TCP/IP connection first made between client(n) and gserver could be somehow "transported" to another application on the same server, intact, and could then be sustained by one of the wserver(n) instances for the long term connection.

I know that web servers do something like this for spreading out server loads. "Load balancing". The main difference here is that the "balancing" is the allocation of a particular user to a particular wserver(n) instance. But I also have the impression that load balancing is a kind of proxying - which I am trying to avoid (since it complicates the architecture and adds overhead as well as a single point of failure.)

This is a conceptual and design question. Don't worry about source code examples, unless they are absolutely essential to get the ideas across. If we pin down an approach, I can code it up.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

等待我真够勒 2024-08-20 18:56:04

您正在寻找的是文件描述符传递。参见 UNP 15.7。 postfix 是该工具的知名重度用户。

What you are looking for is file descriptor passing. See UNP 15.7. One well-known heavy user of this facility is postfix.

泛泛之交 2024-08-20 18:56:04

我很早以前就开发了这样一个应用程序。由于多个服务器无法侦听同一端口。您需要的是让 gserver 侦听众所周知的端口。连接建立后,通过 Unix 套接字将连接传递到其他服务器。一旦连接传递到其他服务器,gserver 就会消失。它可能会死掉,而另一台服务器仍将提供连接服务。

I developed such an application long time ago. Since multiple servers can't listen on the same port. What you need is to have gserver listening on the well-known port. Once connection is established, pass the connection to the other servers via an Unix socket. Once the connection is passed to other server, gserver is out of picture. It can die and the other server will be still serving the connection.

优雅的叶子 2024-08-20 18:56:04

我不知道这是否适用于您的设计,但通常的解决方案(由 xinetd 守护进程实现)是 fork() 然后 exec() 进程。例如,xinetd 可能提供 rlogin、rsh、tftp、telnet 等服务,这些服务实际上是由不同的程序提供的。如果您的 wserver 是系统中已经运行的进程,这对您没有用处。

I dont' know if this applies to your design, but the usual solution (as implemmented by the xinetd daemon) is to fork() and then exec() the process. For example, xinetd may serve services like rlogin, rsh, tftp, telnet, etc. which are actually served by different programs. This will not be useful to you if your wservers are processes already running in the system.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文