[CUWiN-Dev] routeviz questions

[David Young]

On Mon, Jul 25, 2005 at 01:54:33PM -0500, Bill Comisky wrote:
> 
> I had noticed before that I had to delete the 
> /var/db/routeviz_layout.cache file in order for it to update properly from 
> /var/db/vizlinks.  After looking in the code, it appears that the 
> rv_layout_net() function is called to read and write the cache file after 
> the parse_hsls_log() function is called.  The rv_read_cache_file() 
> function parses and configures link metrics in addition to node positions, 
> so it writes over the data from the parse_hsls_log() call.  So once a
> link makes it into the cache file, it's metric is static unless the 
> cache file is deleted.
> 
> Also, I don't see how node/link info would ever get removed from the vnet 
> data structure if nodes/links dissappear from the vizlinks file.
> 
> Correct me if I missed something..

That sounds to me like a serious bug.  I don't think it will be very
hard to fix.  I believe this is the correct algorithm:

Initialize:

        initialize a global "generation" number, N <- 0

Repeat every W seconds:

        1 if the cache exists, read the cache, first; store the cached
          metric in the vlinks; read the generation number from the cache

        2 increase the global generation number, N <- N + 1

        3 if and only if the "vizlinks" file exists and it is newer
          than the cache:

                3b read the vizlinks file

                        3b1 label all of the linkstates read from vizlinks
                            with the generation number

                        3b2 do not overwrite the cached metric, but
                            "scoot" it toward the vizlinks metric---i.e.,
                            metric <- .9 * metric(cache) + .1 *
                            metric(vizlinks)

                            I believe this will help avoid injecting
                            new energy into the "springs" system that
                            will keep the system from converging [1]

        4 delete vlinks / vnodes that are labeled with a generation-number
          that is very far in the past, i.e., W * (N - N(vlink)) > 1 hour.

        5 label as "down" all vlinks / vnodes that remain, if their
          generation-number label is not equal to N.

        6 re-run the springs simulation for "a while" (I don't remember
          how this works---does it stop when no/low motion is reached?)

        7 re-draw

        8 write all of the links & nodes back to the cache file; write
          the generation number to the cache file

Dave

[1] This is one of three recommendations for improving routeviz,
    especially the convergence/stability, that my friend Dave Healy and
    I came up with in a brainstorming session.  I will remind myself of
    the other two, which I have written down, and send them to the list.

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933