Re: Multicast example in ANTS: "Nowhere to send"

[Samarth Shah <shshah@cs.uiuc.edu>]

> > Hi,
> >
> > I believe the multicast capsules get dropped because of the "Nowhere to
> > send" reason when a subscription entry cannot be found at the router.
> > However, this seems to happen randomly for me - on some runs, I get a
> > nowhere to send and on some runs I do not.
>
> whats the duration of the runs?  its plausible that the subscription
> packets were dropped by the os if the run was relatively short.

The runs are of anywhere between 100 and 3500 packets in length. Why would
_any_ subscribe packets get dropped anyways?

I am changing various inter-capsule transmission delays. With a delay of
10 between multicast data capsules, the "nowhere to sends" begin after
packet #459. (It is not random, as I had earlier mentioned; it only
appeared that way because for various inter-capsule delays, it started
dropping capsules for the above reason at different times.)

With a delay of 100 between multicast data capsules, the "nowhere to
sends" begin after packet #184 or so.

I have no idea what the inter-capsule delay for data packets from the
source has to do with the multicast subscribe packets originating from the
receiver. The "nowhere to send" message appears at the source, BTW.

> > I was wondering how I can solve this problem and if there is some way I
> > can make the subscription state hard instead of soft.
>
> send more subscriptions/verify that they were received.  making them hard
> is mostly a matter of statically defining the tree in the protocol,
> then having each node find its place in that tree and finally send packets
> to the neighbors listed in the tree.

Is there some way I can ensure that the MulticastCapsuleCacheValue does
not expire at all? That is, the subscription doesn't expire at all...

-Samarth.

>
> > Thanks and regards,
> > Samarth.
>
> tim stack
>