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

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

Also, BTW, the thing crashes (as in, "nowhere to send" starts appearing
and no data packets leave the source) at different times if I add/remove
some code in MulticastCapsule.java. It's obviously some timing thing.

I tried sending more frequent subscriptions, but that didn't help, either.

Thanks for all your assistance, BTW.

Regards,
Samarth.

PS: Sorry for following up to my own post.

On Wed, 21 Nov 2001, Samarth Shah wrote:

> > > 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
> >
>
>