[LCP]help needed !!!!!!!!!!!!
aditya tomar
adityasinghtomar at hotmail.com
Mon Jan 5 22:00:51 UTC 2004
Hello
I am facing some problem regarding Distributd Interprocess communication,
following is the description please let me know if you have the solution for
this________
Here they are:
The final system must fulfill the following requirements:
1/ Three programs, "broker", "producer" (server) and "consumer"
(client). The communication between nodes will be achieved via sockets.
2/ The broker only runs on one machine, whose address has to be known
by
everyone.
It registers new incoming clients (consumers) and potential servers
(producers).
When a new client declares itself, the broker chooses the less loaded
producer and gives the client and server each other's addresses. It
does
not bother any more with this client/server pair.
Beware that the pairing mechanism must hold on a per-process basis: for
instance, if the client is made of three instances (see 4/ below), the
broker must repeat three times its search for the less loaded node, so
as each client instance can be paired with a different server node.
Periodically, it displays the list of running clients and servers,
together with the load level of each server (I let you determine the
unit, see below)
3/ The producer must define some way of estimating the load of the node
it works on, and tell the broker when asked to.
When in relation with a client, it produces the quantity of artifacts
the client needs (by generating a random amount of time, during which
its load is supposed to increase!!)
When launched, the producer program has two parameters: the name/IP@ of
the broker and the number of instances of "producer" to run on the
local
node.
When a client has been served, the producer notifies the broker for it
to remove this particular pair from its statistics.
4/ The client program has two parameters too: the broker name/IP@ and
the number of client instances that have to be run on the current node.
Each time it receives data from server, it generates a random amount of
time to simulate data usage, then asks for new data until it exits.
>From: Mike and/or Penny Novack <stepbystepfarm at mtdata.com>
>Reply-To: linuxcprogramming at lists.linux.org.au
>To: linuxcprogramming at lists.linux.org.au
>Subject: Re: [LCP]what value does the foo() return?
>Date: Mon, 05 Jan 2004 08:39:27 -0500
>
>I second David's answer
>
>>The interviewer could have been probing for how much you knew about what
>>compilers actually do. Undefined is the correct answer; however many
>>compilers I have met return int values from functions in a CPU register,
>>so for those compilers the return value would be whatever is in that
>>particular register when the function returns.
>>
>>If he seemed unsatisfied did you try asking him what he was looking for?
>>"Undefined" is definitely the correct answer to the question you have
>>given, and asking for more information in this way wouldn't necessarily be
>>seen as bad. The problem with the answer "Undefined" is that it's a one
>>word answer, and interviewers usually want to get to know a bit more about
>>you. Any idiot can read a book and determine the answer to the question,
>>so this answer doesn't in itself differentiate between an experienced
>>programmer and that idiot.
>
>The point is that any ACTUAL compiler implementation will return something
>which is defined. Many programmers are careless and do not worry about
>using results which are formally undefined but "work" (with this compiler,
>version of compiler, this hardwafre, etc.). Very very bad. See, someday
>there will be a new version of the compiler. The guarantee is that CORRECT
>statements will be compiled correctly (and thus behave the same way with
>any compiler) but all bets are off with regard to incorrect statements.
>
>A shop which allows the laxity of not removing bugs which "work" (for some
>wrong reason) is in the position of having to retest every last bit of
>software at every major change. I can't tell you how many times I've had to
>expalin to some programmer that no, there is nothing wrong with the new
>version of the compiler, it isn't under any obligation to reproduce the
>error condiiton behavior of previous versions, that is NOT a bug with the
>compiler but in your program, and it doesn't matter that it "worked" just
>fine in production the last 20 years << and yes, I have seen bugs of this
>sort lurk for that amount of time -- causing great amusement when they
>finally hit and the programmer "winning" the "purple wiener" (a "desk
>ornament" for the programmer causing the last production hang to be kept
>till somebody else's goof causes a hang) is now a vice president in charge
>of Information Systems (a several hundred person shop) of a major Fortune
>500 financial>>
>
>So a BETTER answer to the question would have been something like "The
>result is undefined in C, but of course any particular compiler version
>will be reurning some particular result. However programs must never be
>allowed to use undefined results because then they may unexpectedly fail
>the first time they are compiled by a different compiler version." . I
>don't know what the THAT interviewer was seeking. I know that had I been
>doing the interview, I would have considered the simple answer "undefined"
>correct but unimaginative, possibly just rote knowledge lacking
>understanding of the implications of the problem, while I would have
>considered an applicant giving the fuller answer as exhibiting practical
>knowledge about where the problem lies with using undefined results that
>"work". .
>
>Michael
>
>
>
>
>
>
>
>_______________________________________________
>This is the Linux C Programming List
>: http://lists.linux.org.au/listinfo/linuxcprogramming List
_________________________________________________________________
Start getting interview calls immediately.
http://go.msnserver.com/IN/40245.asp Post your CV on naukri.com today.
More information about the linuxCprogramming
mailing list