X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=ty9WHMiUxQxLT6JW
	0mHLp3R+ruSzHa2Y2B+1PsaSdKzhBesyi9ndrfyFQwsP26JxTp9dFl70lwA/hNdd
	1WyX51mduhXzO8/BSKMAZXGepCikTiz6fL3ATCJxzhtzUnbTgMdZjOey66j4ggEk
	Q8zZWvQa5CO2selMxb1y2j94yEQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=oox5ULJP34q3OSitB33n0u
	CZPMM=; b=arSkq5vwp+ghW5wqWzEmI4VMlSHWSvA8hUa7cIUtrB5cvEBTHCj4vh
	t/Ru9DPc18UrPcMkIihDXQCUjnSfbm5h0qqAty5x3iC1Mcrd8d0eywmvv2R3tGyp
	arFkXBsZ20DrdXfxoNdLtaNrYJjx/rtUxl4iSn4Ezvly4EFthuKDY=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: csmail.cs.umass.edu
Message-ID: <53921106.6020109@cs.umass.edu>
Date: Fri, 06 Jun 2014 15:05:42 -0400
From: Eliot Moss <moss AT cs DOT umass DOT edu>
Reply-To: moss AT cs DOT umass DOT edu
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: annie s <anne DOT stockley AT gmail DOT com>
CC: cygwin <cygwin AT cygwin DOT com>
Subject: Re: using cygwin inetd to start a script on a server to run a java application
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>
In-Reply-To: <CAK03LAoUzNK0t4JFSVNWj6q5qGZY1Wmc0SmKz9kBZHkwGvYeEw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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
indicate:

http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/inetd/launch-service.html#2

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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple