SlowStart Sieve (ToDo)

  • variants [1],

Now, we use an improved version, where we use a simple push-back algorithm by inheriting from SlowStart. This adds a queue to the model, that limits (slows down) the sender to a maximum number of (unhandled) events; in this case that is initially: only one event SlowStart(1).

Note

Without going into details, it important to realize the queue is only added in the model! Depending on the The Machinery (ToDo) it will probably not exist in the computer-code.
For example, the DirectCall machinery will never need, not use this queue

It also shows normal Castle-programmer can focus on the functional aspect of the protocol. The SimpleSieve doesn’t need any extra message to controll this SlowStart (or sliding windows, as is also know) algorithm. That is fully handled in a generic base-protocol.
Additionally, the even more technical aspect of how to send events between (CC) components are completely hidden. As long as both components use the same protocol it will work. ref:TheMachinery will make sure that both components use the same technical details on both ends.

// We have build the sievelist (and reconnect) on a newly found prime ..
SimpleSieve.try(newPrime) on self.generator.found
{
  alias s;

  // Extent the sieve-list ...
  s:= Sieve.new(newPrime);
  s.coprime = self.finder.newPrime;
  if (not self.lastSieve == Ground) {              // .lastSieve == Ground, so not connected, so we have the first Sieve to connect to .generator
    self.generator.outlet = s.try;
    self.generator.outlet.queue.removeLimit();
  } else {
    self.lastSieve.coprime = s.try;
    self.lastSieve.coprime.queue.removeLimit();
  }
  .lastSieve := s;

  self.generator.collect.input(newPrime);   // forward the prime to the Generator
}

Comments

comments powered by Disqus