Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Thu, 31 May 2001 16:43:56 +0400
From: egor duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: egor duda <cygwin-developers AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <48146951254.20010531164356@logos-m.ru>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Re: [RFD]: Egor's proposal for a Cygwin server process
In-reply-To: <20010531124452.G1870@cygbert.vinschen.de>
References: <20010531124452 DOT G1870 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Thursday, 31 May, 2001 Corinna Vinschen vinschen AT redhat DOT com wrote:

CV> I would like to revive the discussion about a sort of server process
CV> providing critical services to Cygwin processes.

CV> The reason is that I found another good example how such a server
CV> could be used: s-uid and s-gid applications and files.

looks reasonable. not that i particularly miss suid bits, but i'd
probably use it extensively if/when it'll be implemented.

CV> So, as far as I can see, we have already three reasons to
CV> invent that server process:

CV> - Secure handles
CV> - IPC
CV> - s-uid, s-gid facility

CV> I think we will find more later on.

CV> So, how is the current "mood" related to such a server process
CV> and how keen are people to work on that?

CV> Has somebody a suggestion how to interact with that server process?
CV> Sockets? Named pipes? Smoke signals?

I'd try to range them from the different points of view:
(first is better, last is worse)

Security:
1. Named pipes.
2. Shared memory (?).
3. Sockets.
4. Smoke signals.

Performance (including both latency and throughput):
(*** this is pure speculation, some testing required ***)
1. Named pipes. Shared memory. (not sure which is better)
2. Sockets.
3. Smoke signals.

Cross-platform support:
1. Smoke signals. :)
2. Shared memory.
3. Sockets. (don't forget, user may want to use cygwin on machine with
no networking installed)
4. Named pipes (nt/2000 only)

a communication between client and server is restricted to local host
only, so, i suppose, we can take "mixed" approach -- use named pipes
on nt/2000 and shared memory on w9x.

but first, i'd try to do some performance testing.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19