Mail Archives: cygwin-developers/2001/09/03/09:55:09
On Mon, Sep 03, 2001 at 05:05:58PM +0400, egor duda wrote:
> 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.
I don't know how that's handled by DDE or RPC either. DDE is a form
of extra communication layer over shared memory so this would perhaps
qualify for speed, though. Just another thought.
> 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.
That's a good idea IMO. OTOH, we should begin with one transport
layer (TL) and then switch over to the higher level ASAP. Later adding
of additional TLs is possible. I have a tiny problem with different
TLs. Since the communication is never initiated by the application
itself but only by the Cygwin DLL, the application developer has no
influence on the TL used. In other words, the Cygwin DLL would have
to decide about the TL by itself. Which decision algorithm do you
think of? Fuzzy? :-)
> 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? */
Dunno, currently. I don't think there should be such a function
at all. On the most basic implementation layer of the communication
the level should be at least open,write,read,close. All TL classes
would have to share this common abstraction. I'm not sure about the
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.
Agree as long as it make sense. E.g. suid() is a application wide
effect. However, this could be handled by one thread of the application
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.
Hmm, I thought of the high-level communication layer (CL) as being
responsible. All functionality layers (FL) have different needs for
datastructures. The CL of FL `foo' has to convert it's data to some
sort of serialized data before calling the TL `bar' which doesn't
interpret the data. Except for a strictly defined header which decides
which CL get's the data when it's received.
> 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
Uh, right.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -