in reply to Rapid inter-machine communication on internal network

I haven't ever tried anything like this, but perhaps this might work.

Could you put a middle layer in that functions as an aggregation point for all the count and price data? Then, have the backend servers (holding banana counts and prices) contact the middle tier whenever their data changes?

The front end would then just make a single call to the middle layer. From the end user perspective, it should be faster than hitting each backend server individually. And, since the backend servers update their count/price only when necessary, you can keep the total transactions down.

  • Comment on Re: Rapid inter-machine communication on internal network

Replies are listed 'Best First'.
Re^2: Rapid inter-machine communication on internal network
by Anonymous Monk on Oct 31, 2006 at 16:53 UTC
    Could you put a middle layer in that functions as an aggregation point for all the count and price data?

    No, that is impossible. The communication absolutely must proceed in two stages.

    In real life, we're not just talking bananas. We're talking bananas and thousands or millions of other items, and minute-by-minute changes. The cost to update a centralized repository for information about all possible items is prohibitive. If an aggregation layer were feasible, I would implement it. I agree that it would be a good approach.

    In the absence of such a solution, streamlining the communication between the boss node and the worker nodes becomes doubly crucial.

[reply]
      Gotcha. I'm also having this nagging notion that concurrency issues are going to arise as you are updating/reading data.
[reply]
        Concurrency is definitely an issue. It's an issue at the level of each individual node, actually, and a solution is already in place which should scale up to handle remote nodes as well. We'll see!
[reply]

In Section Seekers of Perl Wisdom