Re: possible problem with VAT on OSF/1
Author:   Van Jacobson <van@ee.lbl.gov>
Date:     1995/07/20
Forum:    ucb.digital-video

> The only guesses that I have are:
>
> 1)  vat uses the ioctl SIOCADDMULTI to add itself to the group and can
>     sometimes not ioctl SIOCDELMULTI to leave the group.
>
> 2)  DEC OSF/1 has a bug which allows the kernel to think it's still in a
>     group after a socket which added itself with
>     setsockopt(IP_ADD_MEMBERSHIP) goes away.

In all the versions of IP multicast I'm familiar with, closing a
socket causes an implicit SIOCDELMULTI (in systems based on
Deering's code, this happens because in_pcbdetach() is called on
every inet socket close & in_pcbdetach() calls ip_freemoptions()
which calls in_delmulti()).  Since the only time vat would want
to exit the multicast group is when it exits, it lets the close
on exit do the delmulti rather than wasting time by doing it
explicitly.

It's possible that DEC screwed up this part of the kernel but it
seems like they would have noticed it (very few multicast apps do
an explicit SIOCDELMULTI so an OSF system would essentially never
leave any group it joined).  Another possibility is that there's
a child of the vat process keeping the multicast socket open
(ie., if you middle-click on a name to get a unicast session --
for religious reasons John Ousterhout refuses to close open fd's
in the tcl exec code & we got tired of fixing the same bug in
every tcl distribution so sd & vat children inherit the parent's
open fds).

> Since nobody has the source, it's hard to figure out the problem.

Yes, it would be nice if DEC made the source of OSF/1 publically
available so we could fix problems like this.

 - Van