Subject | Re: [IB-Architect] Re : License Question |
---|---|
Author | Joseph Alba |
Post date | 2000-03-23T14:43:39Z |
I'm not sure if I remember right, or I understood the article right. (I
forgot to bookmark it)
But two weeks ago, I read something about inetd at (I think) redhat's
website, and the moral lesson I got was that I should use inetd only for
threads that are used ocassionally and whose connection to the client is
often short.
The author was rather emphatic that for processes that are used for sure,
and used by many clients (just like the IB server), it should be explicitly
executed as a child of the root process, and not depend on the inetd daemon.
But for those programs which maintains long connections to the client, and
which is sometimes long running, or used by many clients in the network,
inetd is not advisable. It should be executed as a process independent of
inetd (but instead, as a child of the root process itself).
Problems associated with inetd for programs with long running connections to
the clients / server are:
1. lost connections
2. wasted resources
Again, I'm not so sure about this. But I just marked it in my head that
running the Interbase server using the inetd daemon is not such a great
idea.
I think, the rationale for inetd is, if you are not running a process for
sure, then you use inetd daemon to watch for any clients who wish to
activate the process, and inetd daemon with run it for you. That way, the
process does not unnecessarily occupy memory / process space if nothing (no
clients) is using it. That's why this is a good place to put things like
ftp, etc...
But if you install a database server in your Linux box, then for sure, you
should be using that box as a database server. So, the added layer of inetd
is quite often unnecessary and could even add a level of complexity and
insecurity on the server.
I would hazard a guess that it is inetd that is causing lost connection
problems on slower network cards, or slower servers.
The reason could be, because if a network device burps even for a very short
moment (which it does sometimes), the inetd daemon thinks the connection is
lost and automatically drops the connection. Meantime, the server is
wondering why the client does not respond, and the client does not know that
the server has dropped the connection. So, with inetd, your network card
should be 100% up all the time with 0% loss.
So, if the server is ran without the inetd, it would be the Linux kernel
which would be managing the network connection, and could be more forgiving
and robust.
But again, this is just a guess. If it hits some mark, good, if not, sorry,
and begging for your indulgence.
Joseph Alba
jalba@...
forgot to bookmark it)
But two weeks ago, I read something about inetd at (I think) redhat's
website, and the moral lesson I got was that I should use inetd only for
threads that are used ocassionally and whose connection to the client is
often short.
The author was rather emphatic that for processes that are used for sure,
and used by many clients (just like the IB server), it should be explicitly
executed as a child of the root process, and not depend on the inetd daemon.
But for those programs which maintains long connections to the client, and
which is sometimes long running, or used by many clients in the network,
inetd is not advisable. It should be executed as a process independent of
inetd (but instead, as a child of the root process itself).
Problems associated with inetd for programs with long running connections to
the clients / server are:
1. lost connections
2. wasted resources
Again, I'm not so sure about this. But I just marked it in my head that
running the Interbase server using the inetd daemon is not such a great
idea.
I think, the rationale for inetd is, if you are not running a process for
sure, then you use inetd daemon to watch for any clients who wish to
activate the process, and inetd daemon with run it for you. That way, the
process does not unnecessarily occupy memory / process space if nothing (no
clients) is using it. That's why this is a good place to put things like
ftp, etc...
But if you install a database server in your Linux box, then for sure, you
should be using that box as a database server. So, the added layer of inetd
is quite often unnecessary and could even add a level of complexity and
insecurity on the server.
I would hazard a guess that it is inetd that is causing lost connection
problems on slower network cards, or slower servers.
The reason could be, because if a network device burps even for a very short
moment (which it does sometimes), the inetd daemon thinks the connection is
lost and automatically drops the connection. Meantime, the server is
wondering why the client does not respond, and the client does not know that
the server has dropped the connection. So, with inetd, your network card
should be 100% up all the time with 0% loss.
So, if the server is ran without the inetd, it would be the Linux kernel
which would be managing the network connection, and could be more forgiving
and robust.
But again, this is just a guess. If it hits some mark, good, if not, sorry,
and begging for your indulgence.
Joseph Alba
jalba@...