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


Hi!

Monday, 03 September, 2001 Corinna Vinschen vinschen@redhat.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


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