使用 inetd 或不使用 inetd...我什么时候应该在我的网络服务器程序中使用 inetd？
谁能给出一组简明的现实世界考虑因素，以推动选择是否使用 inetd 来管理充当网络服务器的程序？
（如果使用 inetd，我认为它会改变程序中网络代码的要求，所以我认为它肯定与编程相关，而不是一般的 IT）
这个问题是基于我见过的一个实现，该实现使用由inetd 启动一个网络侦听器，然后该侦听器将永远运行并承受持续的重负载。 它似乎不太适合教科书 inetd 使用配置文件（按需、不经常使用、轻量级），这让我对更普遍的问题产生了兴趣。
Can anyone give a concise set of real-world considerations that would drive the choice of whether or not to use inetd to manage a program that acts as a network server?
(If inetd is used, I think it alters the requirements around networking code in the program, so I think it's definitely programming-related and not general IT)
The question is based around an implementation I've seen that uses a control program managed by inetd to start a network listener that then runs forever and takes constant and heavy load. It didn't seem like a good fit with the textbook inetd usage profile (on-demand, infrequently used, lightweight) and got me interested in the more general question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这取决于您的服务的使用模式。 如果您的守护进程的启动时间很短，并且您希望它不经常使用，那么 inted 可能是一个不错的选择。 它减少甚至消除了编写任何额外网络代码的需要。
如果您的守护进程更重量级或更频繁使用，那么您最好将其独立编写。 您可以轻松地编写一个
init.d脚本和一些conf.d配置来配合它，管理员管理起来并不困难。 如今，大多数编程语言都具有易于使用的套接字库，因此在许多情况下，网络代码甚至可能并不那么困难。根据我的经验，我发现现在很少有管理员熟悉 inetd。 大多数守护进程只提供自己的初始化脚本。 事实上，在我管理的几百个系统中，我根本想不出有哪个系统是通过 inetd 启动任何东西的。 这是值得考虑的事情。
It depends on the usage pattern for your service. If the startup time for your daemon is low, and you expect it to be used infrequently, then inted might be a good fit. It reduces or even eliminates the need to write any additional networking code.
If your daemon is more heavyweight or more frequently used, you're probably better off writing it standalone. You can just as easily write an
init.dscript and someconf.dconfiguration to go with it and it will be no harder for an admin to manage. Most programming languages these days have easy to use socket libraries so in many cases the networking code may not even be that difficult.I've found in my experience that few admins these days are familiar with inetd. Most daemons just provide their own init script. In fact, of the few hundred systems which I manage I can't think of a single one that launches anything through inetd at all. That's something worth considering.
从操作的角度来看，连接到 inetd 将使您的服务更容易管理，因为 inetd 允许系统管理员控制几乎所有与您的程序进行网络通信的方式。 但是，它需要您对程序进行一些代码更改。 此外，它可能不如一开始就让程序作为守护进程运行那么有效。
编辑：我个人从不使用 inetd，并且总是选择将服务器进程编写为独立的守护进程。
Hooking into inetd will make your service slightly easier to manage from an operational point of view as inetd allows a sysadmin to control practically all of how network communications with your program happens. However it will require you to make a few code changes to your program. Also, it may not be as efficient as just making your program run as a daemon to begin with.
EDIT: I personally never use inetd and always opt to write server processes as standalone daemons.
我认为在决定使用 inetd 时值得考虑的另一个因素是处理请求的进程平均消耗多少内存？ 如果这个值相当高，那么在高负载下，您可能会面临内存不足的风险（因为 inetd 分叉）。 同一服务器可以以多线程或选择轮询方式实现，可能允许每个连接更高的负载/更少的内存。
I think another factor worth considering when deciding to use inetd is how much memory the process handling the request consumes on an average? If this is fairly high, then under high load you risk running out of memory (since inetd forks). The same server might be implementable in a multithreaded or select-poll manner possibly allowing for higher load / less memory per connection.
您可以使用 inetd 为通过 stdin/stdout 运行的简单程序提供 TCP/UDP 功能。
如果没有 inetd，您的程序将需要管理一系列问题，包括网络接口、套接字、分叉、资源限制等。
You can use inetd to give TCP/UDP capabilities to simple programs that operate over stdin/stdout.
Without inetd, your program will need to manage a slew of concerns, including network interfaces, sockets, forking, resource limits, etc.
您正在考虑什么替代策略？
inetd 是确保服务器在操作系统以适当的运行级别启动时启动的好方法。 即使您确实将服务器设计为具有其他一些管理机制，inetd 仍然可以非常简单地包装所有命令。 毕竟这只是 shell 脚本。
What alternative strategy are you considering?
inetd is a good way of ensuring your server starts when the OS boots in the appropriate run level. Even if you do design your server to have some other management mechanism, inetd could still wrap all the commands quite simply. It's only shell scripts after all.