[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