Kite update Session.
Session extend the Katabatic update session to the Kite router level. Mainly by managing Track update.
Difference between Kite & Katabatic sessions:
- In Katabatic, segments are actually moved before the revalidation, then during the revalidation, contacts and topologies are adjusteds
- In Kite, nothing is moved until the revalidation. Requests for segment displacement are queued for the session.
Asymmetry between invalidation & revalidation:
- When a TrackSegment (or directly an AutoSegment) is invalidated both associated AutoSegment and TrackSegment are invalidated (through the Observer mechanism).
- When an AutoSegment is revalidated, the TrackSegment is not immediatly revalidated. See the revalidate algorithm for more details.
Indirect TrackSegment invalidation:
For details on how Katabatic Sessions works, have a look to Katabatic::Session.
The Session Mechanism.
Delayed modification procedure :
- Modifications events are recorded (queued) into the Session. At this step, no modification are actually done, the data-base retains it's previous state and coherency.
- The
revalidate()
procedure is called (or the Session is closed), then all the modification events are applied. The data-base is in now in it's new state.
The Revalidate Algorithm.
Revalidation steps :
- Process all remove events. detach TrackSegment from their Track, but do not remove the pointer from the internal
vector
.
- Pack all Track in which removal have took place.
- Process all insert events. This is the time TrackSegment are moved into their new Track (physical displacement). It is at this point that the invalidation of both AutoSegment and TrackSegment is done.
- Call the Katabatic::Session::revalidate() method which will recompute the correct contact extensions and topologies. After this step the Katabatic data-base is up to date, but not the Kite one. AutoSegment are revalidated.
- Recompute the canonical position of source and target of all invalidateds TrackSegment (take account of extention modifications). The set of invalidated TrackSegment is computed from the revalidated AutoSegment, that is AutoSegment that are canonical.
- Perform a sort() on all Track that have been modifieds.
- Now that the size of the segments have been accurately computed, look for revalidateds TrackSegment that:
- Can be reduced, generate a track remove event.
- Must be raised, generate a routing event (put into the queue).
- Process the additional track remove events.
Note: We cannot use the Observer mechanism to automatically update TrackSegment from an AutoSegment, because we must wait for all AutoSegments (canonical or not) involved into the TrackSegment to be up to date before we can update it.
Note: Have to talk about the special case when new canonical AutoSegment appears after dogleg creation.
The Lookup Mechanism
There are two lookup mechanisms: