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 19:13:05 +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: <9023457349.20010903191305@logos-m.ru>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Re: CYGWIN SERVER: Some questions
In-Reply-To: <20010903155458.A30211@cygbert.vinschen.de>
References: <20010903140332 DOT C23714 AT cygbert DOT vinschen DOT de>
 <1015829882 DOT 20010903170558 AT logos-m DOT ru>
 <20010903155458 DOT A30211 AT cygbert DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=Windows-1251
Content-Transfer-Encoding: 8bit

Hi!

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

ÑV> That's a good idea IMO. OTOH, we should begin with one transport
CV> layer (TL) and then switch over to the higher level ASAP. Later adding
CV> of additional TLs is possible. I have a tiny problem with different
CV> TLs. Since the communication is never initiated by the application
CV> itself but only by the Cygwin DLL, the application developer has no
CV> influence on the TL used. In other words, the Cygwin DLL would have
CV> to decide about the TL by itself. Which decision algorithm do you
CV> think of? Fuzzy? :-)

 not at all :). For example: w9x ==> Shared Memory (as we don't care
 for security here); nt/2000 ==> Named pipes (because they exist on
 them)

>> 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? */

CV> Dunno, currently. I don't think there should be such a function
CV> at all. On the most basic implementation layer of the communication
CV> the level should be at least open,write,read,close.  All TL classes
CV> would have to share this common abstraction. I'm not sure about the
CV> level of this abstraction, though.

>> 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> Agree as long as it make sense. E.g. suid() is a application wide
CV> effect. However, this could be handled by one thread of the application
CV> which is treated as responsible then.

>> 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> Hmm, I thought of the high-level communication layer (CL) as being
CV> responsible. All functionality layers (FL) have different needs for
CV> datastructures. The CL of FL `foo' has to convert it's data to some
CV> sort of serialized data before calling the TL `bar' which doesn't
CV> interpret the data.  Except for a strictly defined header which decides
CV> which CL get's the data when it's received.

Of course. I just don't know a convenient and fast way to perform such
serialization in more or less generic (and type-safe) manner. simple
bunch of memmove()s is prone to subtle errors. this won't be a big
problem until we don't make extensive use of this mechanism and don't
pass complex structures though it.

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