Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Tue, 4 Sep 2001 11:28:02 +0200 From: Corinna Vinschen To: cygdev Subject: Re: CYGWIN SERVER: Some questions Message-ID: <20010904112802.B7039@cygbert.vinschen.de> Reply-To: cygdev Mail-Followup-To: cygdev References: <20010903140332 DOT C23714 AT cygbert DOT vinschen DOT de> <999521536 DOT 31781 DOT 12 DOT camel AT lifelesswks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <999521536.31781.12.camel@lifelesswks>; from robert.collins@itdomain.com.au on Tue, Sep 04, 2001 at 07:55:35AM +1000 On Tue, Sep 04, 2001 at 07:55:35AM +1000, Robert Collins wrote: > On 03 Sep 2001 14:03:32 +0200, Corinna Vinschen wrote: > > 1. Platform independent (from a Wincentric point of view, 9x/NT) > IMO, for reliability we want a true NT service on NT, and a auto-spawn > capability for 95. (ie the first cygwin process spawns the daemon, and > it stays running thereafter). Ah, and don't forget the the Cygwin code has to stay self-acting. If it's impossible to start or to contact a server it should _not_: - Give up. - Hang - Dramatically slow down. All functionality which is still possible should work and all calls which actually need the server could return some ENOSYS error code. > > 2. Fast > > 3. Reliable > > 4. Secure > > 5. Easy to use > > 6. Expandable > > [...] > > I've recently looked into the MSDN and while I've no idea how to > > use RPC (I'm talking about the Windows version, not ONC RPC) and > > just a bit of knowledge about DDE (one client/server app 5 years > > ago) I'm under the impression these two methods could be the way > > to go. Both are available on 9x and NT and both have the > > `ImpersonateClient' feature to be securable against unprivileged > > access. If we prefer speed we should take shared memory but we > > would then need another protocol for user context sensitive > > functionality like S_ISUID stuff. Anyway, food for discussion. > DDE is quite an old protocol by MS standards, and is very transaction Is that bad? AFAICS, DDE is pretty easy to use, it has the impersonation facility on NT and it uses shared memory as low-level TL which _could_ mean, it's fast. > oriented. I suspect that COM or RPC is the way to go. COM is very easy > to use, and very extensible. On the down side COM requires a bunch of > registry entries defining the available interfaces before it can be > used. Lastly, COM use requires a set of MSVC compatible options to be > passed to gcc - I'm sure we've all seen the occasional message > referencing this. I don't know what that means for us though. It means, we have to implement the whole COM interface inside of Cygwin in plain C. Otherwise we would have to recompile everything. Not good. However, that doesn't kick COM out of the race. After implementing the TL access to COM in plain C we can naturally construct a C++ interface over it. > Lets rule named pipes out now (win9x). Yep, for now. > For reliability we need a server that cannot get 'hung'. Ie if a client > dies, the server must be able to notice and clean up. Shared memory, > unlike the other options, doesn't have a transaction based API - so we > would need to implement something like that to prevent such a deadlock > occuring. That seems more complexity than we need, and RPC and COM have > quite efficient data transferring means anyway. So I think we should > also rule out shared memory as the communication protocol. Shared memory > could be a tool used by the daemon though. Just more food for though. Yep, I agree. No shared memory as TL (except for DDE as it's low- level layer :-)) > That leaves > Sockets/RPC/COM. I've no preference or objection here. Sockets are insecure. Sockets are not really reliable, at least on Windows. Especially the cleanup problem when an application exits w/o closing the socket first. IMO DDE/RPC/COM are remaining choices. > > The next thingy is, how to implement the high level protocol? > > It should be expandable so that a new server feature doesn't > > neccessarily imply a change in the protocol e.g. by using > > a function oriented interface like open_server(), write_server(), > > read_server(), close_server() with a defined structure or string > > for sending and receiving data. Or we prefer the ease of use over > > the easy expandability. A C++ class oriented interface comes to mind. > > Anyway, food for discussion. > > Hmm. My thoughts here are that we have two basic ways we can interface > to the daemon - sync and async. We also have two basic approaches for > writing code that interfaces... > > for sync calls > > shm_get(foo, bar){ > return daemon_shm_get(foo, bar); > } > > or > shm_get(foo,bar){ > return (typecast ) daemon_synccall(DAEMON_SHM_GET, foo, bar); > } > > Personally, I prefer the 1st style - it's less prone to human error. I'm So you would prefer a plain C interface. I like the `deamon_shmget()' idea. I was talking of a C++ class oriented interface since I think it's easier to use and maintain, though. Think of a class structure like that: class transport_layer; // Only called from the HL layer which we // call `deamon' here. class com_transport_layer : public transport_layer; ... class daemon; class shm_daemon : public daemon { public: get(); } ... A system call in Cygwin: shmget (foo, bar) { shm_daemon shm; if (shm.available ()) // E.g. ask if daemon is present. return shm.get (foo, bar)l set_errno (ENOSYS); return -1; } > Async calls have a similar issue, with the callback mechanism needing thought as well. (Do we need async daemon calls?) Good question. I don't know. Somebody else knows? > > Which functionality would be thankful to be implement using a server? > > Currently I know of > > > > - Secure tty's (No access to other processes handles). > > - suid, sgid applications (start a privileged app on behalf of a non- > > privileged app). > > - ipc (shm, sem, msg). > > - pthreads synchronisation stuff (did I get that right?) > > Nearly. Pthreads pshared (process shared) stuff. > > > Let's add stuff here as it comes. > > IMO, FIFO's belong here. Yup, that was already mentioned by Egor. > > I would like to ask you all if, and if, how much you want to get > > involved in that project? Which part do you want to care for? > > I'm actually rarely using cygwin these days, I'm spending much of my > time on linux day to day. However I'm still keen to support cygwin, so > I'll put my hand up for the pthreads stuff, and FIFO's, and potentiall > some of ipc as well. > > > Hoping for enthusiastic replies, > > _enthusiasm_. That sounds good :-) > Rob Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.