From: "Geo" 

When you do a traceroute, the first thing it does is build a list of IP
addresses that respond with a timeout packet, it then has to go and do a
dns lookup on each of those IP addresses and those lookups could all be
done simultaneously, in fact once you have the route (that list of IP's) it
can go multithreaded to analyze each hop (dns, ping, arin lookups,
whatever) to increase the speed of getting results.

Geo.

"Ellen K."  wrote in message
news:e19b111u8u9cd4tho3p0pkmoa9nkb7d5e9{at}4ax.com...
> Yeah, but how does it know the next dns name already if it hasn't yet
> resolved the one it's trying to resolve now?
>
> On Wed, 16 Feb 2005 20:18:08 -0500, "Geo"
 wrote in
> message :
>
> >Nope. Not for resolving the dns names which is what takes so much time.
> >
> >Geo.
> >
> >"Ellen K."  wrote in message
> >news:89b611h4bts4p57qfcopdqppshn2lhejm2{at}4ax.com...
> >> ?  Doesn't each one have to wait for the previous one?
> >>
> >> On Tue, 15 Feb 2005 23:14:57 -0500, "Geo"
 wrote in
> >> message :
> >>
> >> >"Paul Ranson"  wrote in message
> >news:4211fab9{at}w3.nls.net...
> >> >
> >> >> But fibers came after threads, so fibers are
generally only used
when
> >the
> >> >> application can benefit from doing its own
scheduling. A search for
> >fiber,
> >> >> sqlserver and msdn should turn up a couple of
interesting articles.
> >> >
> >> >I know the perfect usage for fibers, it could be used to create a
really
> >> >fast traceroute program. One thread to do the traceroute
but multiple
> >fibers
> >> >each resolving a single node along the route. Because
each has to wait
> >for
> >> >input, the app thread should do the scheduling based on demand.
> >> >
> >> >Have I got the idea of your scheduling comment?
> >> >
> >> >Geo.
> >> >
> >>
> >
>

--- BBBS/NT v4.01 Flag-5