Mail Archives: cygwin-developers/2001/09/04/05:28:10
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.
- Raw text -