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: Mon, 3 Sep 2001 17:05:58 +0400
From: egor duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.53 RC/4)
Reply-To: egor duda <cygwin-developers AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <1015829882.20010903170558@logos-m.ru>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Re: CYGWIN SERVER: Some questions
In-Reply-To: <20010903140332.C23714@cygbert.vinschen.de>
References: <20010903140332 DOT C23714 AT cygbert DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Monday, 03 September, 2001 Corinna Vinschen vinschen AT redhat DOT com wrote:

CV> The most important question IMO is, how do we design the communication
CV> protocol? It should combine all qualities which can't live together in
CV> reality but only on marketing papers:

CV> 1. Platform independent (from a Wincentric point of view, 9x/NT)
CV> 2. Fast
CV> 3. Reliable
CV> 4. Secure
CV> 5. Easy to use
CV> 6. Expandable

server should know when client dies (i'm not sure if it's implied by
"Reliable"). that's, btw, is a "Con" for at least Shared memory,
probably for DDE and RPC too.

CV> What did we found to date? We already discussed the transport layer
CV> back in June but we have no result so far. Possible transport layers
CV> are:

CV> - Sockets (Pro: Platform independent, Easy to use, Con: Secure)
CV> - Shared memory (Pro: Platform independent, Fast, Con: Secure)
CV> - Named pipes (Pro: Secure, Con: Platform independent)
CV> - DDE (Pro: Platform independent, Secure, Con: Easy to use???)
CV> - RPC (Pro: Platform independent, Secure, Con: Easy to use???)
CV> - COM (Pro: Platform independent, Con: Easy to use???)

As for transport layer, i believe we should design the protocol in
such a way that transport layer can be (more-or-less) easily switched.
i.e. we create "transport-level" abstract class (see class
server_connection below), and several implementations of such
interface using all or some of beforementioned OS primitives.

typedef enum {
  conn_status_not_established, /* not connected (yet) */
  conn_status_ready,           /* connection established, no requests currently */
  conn_status_processing,      /* server is processing the request */
} conn_status;

class server_connection
{
  conn_status connection_status;
public:
  conn_status get_connection_status ();
  int make_connection (int timeout);
  int accept (int timeout);
  HANDLE ready_to_read ();  /* HANDLE is signalled when connection is ready to read */
  HANDLE ready_to_write (); /* ... ready to write */
  int read (char* buf, int size);
  int write (char* buf, int size);

  /* call_server (...); */
  /* is there any need for "flat" connection in the case of RPC or
     COM? */

  int close ();
}

hmm, this makes abstract connection look similar to yet another
fhandler...

i think connections should be made on per-thread basis, rather than
per-process to avoid a host of problems with thread-safety. i think
thread-safety should be assured by server.

CV> The next thingy is, how to implement the high level protocol?
CV> It should be expandable so that a new server feature doesn't
CV> neccessarily imply a change in the protocol e.g. by using
CV> a function oriented interface like open_server(), write_server(),
CV> read_server(), close_server() with a defined structure or string
CV> for sending and receiving data.  Or we prefer the ease of use over
CV> the easy expandability.  A C++ class oriented interface comes to mind.
CV> Anyway, food for discussion.

here, the only problem i see is convenient way to linearize-delinearize
(or marshall-unmarshall, in MS terminology) complex data structures to
linear connection. native RPC dlls do contain some functions to
perform marshalling, but i've never used them and suspect they need
some kind of IDL (interface definition language) with appropriate
compiler.

CV> Which functionality would be thankful to be implement using a server?
CV> Currently I know of

CV> - Secure tty's (No access to other processes handles).
CV> - suid, sgid applications (start a privileged app on behalf of a non-
CV>   privileged app).
CV> - ipc (shm, sem, msg).
CV> - pthreads synchronisation stuff (did I get that right?)

mkfifo and fifo's

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