There seems to be some basic misunderstanding on this point. It is
not inherently necessary to run the super server ([x]inetd) to be
able to accept multiple concurrent connections on the same port, it
is only due to a limitation in the MUMPS language that this is so.
The reason is that in languages like C or Java it is possible to
create a socket that listens on a specific port number and then
accept new connections that will be handled by a separate process or
thread. Interestingly, it is common under Unix to run a number of
standalone "daemon" programs (telnetd, ftpd, httpd, rpc.mountd, etc.)
all which can run quite independently of the super server. However,
there needs to be a separate daemon listening on any port on which
you are willing to accept a connection. What the super server does
for you is allow you to run ONE process that listens for connections
on every port for which it is configured to accept connections, and
then after accepting a connection, it will start the appropriate
program to handle it. For example, sendmail itself might not listen
on port 25 (though it usually does), but could instead be invoked
after the super server has accepted a connection on port 25.
To understand the MUMPS issue, think of the HL7 package. Since there
is no accept call, you are forced to write a program that listens for
connections on whatever port you choose to use for HL7, then once
another system has connected, that SAME program is busy handling the
connection (running the application protocol), and so all further
attempts to connect to that port will be rejected until the
connection is closed. In the HL7 package, such a process is called a
listener and, in particular, a "single threaded listener". The HL7
package also supports what is known as a multi-threaded listener, but
sine it is impossible to implement such a thing natively in MUMPS, it
is run as a service under VMS, which is the equivalent to running
under the control of [x]inetd under Unix.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The policy of being too cautious is
the greatest risk of all."
--Jawaharlal Nehru
On Aug 2, 2005, at 1:12 AM, Zeno Davatz wrote:
On 7/31/05, Nancy Anthracite <[EMAIL PROTECTED]> wrote:
If you are using a recent CPRS and version of VistA, it is built
in. It
usually tries to connect with the new broker and then defaults to
the old if
the new does not work. It has worked with Windows for quite a
while, but
only recently with GTM and Linux. You have to work with xinetd if
you want
to connect more than once as I understand it.
Ok, I do not have xinetd on my Gentoo-Linux installed and I would
prefer not to install it. The reason why I believe I do not have to
install it is, that it is not installed per default on Ubuntu, Debian
and Gentoo. So I'm asking once again: Why not use a protocol that is
installed by default on any Linux box; like SSH and Rsync? They will
open there default port and there services are mostly used for many
things.
Thanks
Zeno
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
