[LCP]design issues
Mike and/or Penny Novack
stepbystepfarm at mtdata.com
Wed Aug 27 19:46:02 UTC 2003
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.
More information about the linuxCprogramming
mailing list