Re: [LCP]design issues

[Mike and/or Penny Novack <stepbystepfarm@mtdata.com>]

Cart before horse?

>     i am going to develop a server program for linux platform. the
> scenario is of One Server - Multiple Clients. which of the following
> technology be used - pipes, FIFO, Message Queues or threads? which one is
> the best/widely used? 


Mehul,
   I'd say to use the one which makes the best fit with your model (the 
ABSTRACT design of this multiclient server interaction).

   OK, I'm going to say something a lot of you may or may not agree 
with. The place to start is NOT with the implementation in some concrete 
langauge. This is a problem in "concurrent processing" where there is no 
guarantee that some of the processes are going to be well behaved. For 
example, no reason at all to suppose that some clients won't simply "go 
away" instead of continuing their interaction with the server like 
trained seals. Your server needs to be able to cope with this among 
other interesting problems.

   So FIRST learn about the design of such systems. Here you have a 
server, multiple clients coming and going at irregular intervals, 
operating at different speeds, and maybe disappearing without ever 
completing expected communications. Only after you understand how this 
sort of thing can be safely and reliably handled should you worry about 
"how best do I code this in language C" (in other words, how do I make a 
CONCRETE as opposed to abstract implementation). Notice if you have done 
a correct model, you will have a set of abstract operations and will 
simply be implementing these. This separates errors into two kinds -- 
the abstract operation may be wrong (logic or design error) OR your 
implementation of that abstract may be incorrect. But you may be able to 
(SHOULD be able to) come up with a method of testing the latter 
independent of the server-client relationship.

   Can anybody suggest some good books for Mehul? Something on "the 
design of concurrent processes" with sections on server with multiple 
clients.

Michael

PS ----- Abstract design is always a good idea with any non-trivial 
programming task.  In other words, FIRST come up with a model that would 
correctly carry out the task. THEN code the implemtation of that model. 
Essentially you are pretending that some imaginary abstract "machine" 
carries out the task and you are just coding  the "emulator" for that 
machine. Believe it or not, this tends to be much faster than the direct 
approach (just jumping into the code), much more likely to be a CORRECT 
solution of the problem, and MUCH easier to debug.