This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CYGWIN SERVER: Some questions


On 03 Sep 2001 14:03:32 +0200, Corinna Vinschen wrote:
> ========================================================================
>      FOOD FOR DISCUSSION  FOOD FOR DISCUSSION  FOOD FOR DISCUSSION  
> ========================================================================
> 
> I have some questions about our "Cygwin server project" which is
> about to start as soon as we have discussed how to implement
> the client/server protocol and how to manage differences between
> NT and 9x based OSes.
> 
> The most important question IMO is, how do we design the communication
> protocol? It should combine all qualities which can't live together in
> reality but only on marketing papers:
> 
> 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). 

> 2. Fast
> 3. Reliable
> 4. Secure
> 5. Easy to use
> 6. Expandable
> 
> What did we found to date? We already discussed the transport layer
> back in June but we have no result so far. Possible transport layers
> are:
> 
> - Sockets (Pro: Platform independent, Easy to use, Con: Secure)
> - Shared memory (Pro: Platform independent, Fast, Con: Secure)
> - Named pipes (Pro: Secure, Con: Platform independent)
> - DDE (Pro: Platform independent, Secure, Con: Easy to use???)
> - RPC (Pro: Platform independent, Secure, Con: Easy to use???)
> - COM (Pro: Platform independent, Con: Easy to use???)
> 
> 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
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.

Lets rule named pipes out now (win9x). 

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.

That leaves
Sockets/RPC/COM. I've no preference or objection here.  

> 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
pretty sure the COM style supports that - you define the interface, the
COM runtime does the rest. Not having done MS RPC I'm not sure either
way, and as for sockets AFAIK the second way is the only one we'd be
using. (Whether we wrap that in some nice #defines or not). Not making a
judgement call here, just more food to think on.

Async calls have a similar issue, with the callback mechanism needing thought as well. (Do we need async daemon calls?)

> 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.
 
> 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_.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]