This is the mail archive of the
mailing list for the Cygwin project.
Re: using cygwin inetd to start a script on a server to run a java application
- From: Eliot Moss <moss at cs dot umass dot edu>
- To: annie s <anne dot stockley at gmail dot com>
- Cc: cygwin <cygwin at cygwin dot com>
- Date: Fri, 06 Jun 2014 15:05:42 -0400
- Subject: Re: using cygwin inetd to start a script on a server to run a java application
- Authentication-results: sourceware.org; auth=none
- References: <CAK03LAoZUgeOaH-n9AuxfF7b4WAz7ij4jTDOPEWkyk5==FJukQ at mail dot gmail dot com> <5390CFF2 dot 2060501 at cs dot umass dot edu> <CAK03LAoUzNK0t4JFSVNWj6q5qGZY1Wmc0SmKz9kBZHkwGvYeEw at mail dot gmail dot com>
- Reply-to: moss at cs dot umass dot edu
Dear Annie -- Again, I am not a deep expert, but the TCPView output
looks to be what I would expect if the inetd forks a copy of itself
to handle a new client connection. A TCP connection (as you probably
know) is distinguished by *both* the local host/port pair *and*
the remote host/port pair. So a local port can certainly be used
in multiple connections. It will, however, be a different socket
within the server.
I notice that the Java process is also listening, but on a different
local port. I am guessing that that is for the intended RMI connection.
That is, the point of the example-server port is to give the ability
to spawn Java jobs. They then listen on their own port to establish
an RMI connection. I presume that either the spawned inetd or the
spawned Java somehow communicates back to the remote client the port
number for the RMI protocol, namely 57088, so that the remote client
can connect to the listening Java instance.
I think maybe your issue has to do with wait/nowait in the inetd.conf
entry. One setting causes inetd itself to accept the connection, the
other causes the spawned server process to do it. Which way it should
work depends on the server process. The two ways are:
1) wait: spawn only ONE server process and it handles all bind requests;
inetd starts it only if a new request comes and the server process
is not already running. This is the normal case for udp/datagram
types of services.
2) nowait: spawn a server process for each request; inetd handles the
bind. This is normal for tcp.
So, if for RMI the model is ONE server process that then handles all
RMI requests for that host, even though the request may be for a tcp
connection, wait would be correct. That is what this page seems to
I see that you wrote nowait. I suggest changing it to wait. I am copying
this reply to the cygwin list for the archives.
Regards -- Eliot Moss
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple