Hi,

But you might be right, since change in the kernel routing table might happen in A, before the whole A-B-C route is ready. I will try doing the local-repair after eg. 5 sec has passed. I haven't thought of this.

Ethereal is another good point, I should have tested it more before sending this to the list.

OK, no problem. 5 seconds waiting sounds like a good idea to try.

Also, is there a config file to make GIST send its QUERY-s faster?

It is not yet in the config file. You should try to start GIST with "-timer <value>", where <value> is the number of milliseconds between refreshes. 30000 is the default.

PS:

Sorry, but I'm quite limited on Skype: no net at home, and I do not have that fired up at the lab, maybe I set it up at later date.

No problem, was just an idea to speed up helping you :)

with GIST debug mode 2: from A's sendmsg call to A's final recvmessage, it took about 1.2 sec!

with GIST no debug: it took about 0.2 sec

from these times, GIST takes about 90% (though I heard call setups last long, 1.2 sec on this 3 node wired setup made me jump)

Wow, thats long. 0.2 seems fine. There are some portions of code which are only executed in debug mode, but this does not explain 1 additional second. Did you run GIST over SSH or something like this? Then the delay could be caused by this.

Christian Dickmann