Mail Archives: cygwin-developers/2001/09/03/11:19:45
Hi!
Monday, 03 September, 2001 Corinna Vinschen vinschen AT redhat DOT 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 AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -