[LCP]help needed !!!!!!!!!!!!
Mike and/or Penny Novack
stepbystepfarm at mtdata.com
Tue Jan 6 01:25:39 UTC 2004
Let me give a LITTLE more help. The first thing you need to do is
complete the process specification. Don't begin design till you have a
That's right, as it satnds, the specification for this porcess is
incomplete. It's incomplete in the same way that analysts always begin
with incomplete specifications because those giving us those
specifications think only about how the process in terms of "when
everything works". They do NOT stop to consider what this process should
do if one or more things has gone wrong.
For example, the overall process depends upon communications between
independent processors and these communications can fail, one or more of
the processors can be dead and not responding. A robust real world
solution must take that into account. Thus......
Suppose the broker is unable to communicate with one of the producer
processes. What should happen? Obviously the overall process could
continue at reduced capacity and that's probably what would be desired.
But maybe something else also (like should the "broker" send a message
to the support console informing a human "producer process ID=xyz
appears to be dead").
Suppose a producer process is unable to communicate with the broker.
Should it just sit there waiting to get through? Or more likely, since
it has a queue of tasks waiting (remember, least loaded producer doesn't
mean UNloaded producer) should it queue the "task completed" report for
sending later and meanwhile get on with the next task (and wait only if
its task queue is empty).
Look at the (initial) specification carefully for all these "holes"
that need to be plugged. In the real world, after coming up with
reasonable alternatives, you would call a meeting of the "business
clients" who gave you this task to get their decision/approval
onexpansion the specification of the behavior of the distributed
process covering all these "unforseen events" << if you are an
experienced analyst they will like YOUR proposals about "what to do
if..." but ultimately that's their call -- and it's wrong to blame THEM
for not having noticed these gaps in the specification -- your job is
not just to "do what the customer asked for" but to be their ANALYST >>
If this is a class project, the teacher may be waiting for you to
have noticed "something missing in the specification" and may then tell
you the "what to do ifs" (and maybe only students who notice the problem
and ask get them). Or quite possibly might tell you "just do something
reasonable" letting you pick. A lot depends on the teaching style.
The reason I am pointing this out to you is that design omissions of
this sort are quite difficult (expensive) to fix once coding has begun.
You do NOT want to discover during testing of your process that it locks
up and you have to redesign handling of what you thought were single
objects into processing of a queue, decide on wait times, insert
confirmations of "message recieved" (look up "The Two General Problem"),
etc. A lot has been left out of the specification as you have it now.
Fill in those details because that WILL affect your implementation choices.
More information about the linuxCprogramming