Jonathan Stone <jonathan@dsg.stanford.edu> writes:

> Mmmm. I was going to say "yes". But, UTSLing, perhaps a PF_INET socket
> can *join* as many multicast groups as it wants, but only send on (at
> most) 20?  That seems to match the use of ip_moptions in ip_output().

It's IP_ADD_MEMBERSHIP that has the limit; there is an array of joined
groups in struct ip_moptions (see netinet/ip_var.h).

There is no state kept on sockets when sending to multicast groups;
one can write a program to cycle through them all.  But be careful -
I've seen buggy LAN switches get very wedged up from this, and it's
abusive to DVMRP routers which will end up pruning every group.

> More ULTSing shows a comment that all 20 ``must fit in one mbuf''; but
> I don't recall what the reason for that constraint was (if indeed it
> dates back to Steve Deering's code).

Currently struct ip_moptions is malloced (see ip_setmoptions in
netinet/ip_output.c), but I believe it used to be in a (non-cluster)
mbuf.  I dimly recall that 20 was the biggest round number of
memberships such that everythihng would still fit in 236 bytes, or
something like that.  But that was I think 17 years ago.

> Kernels are now bigger than physical RAM on the machines I was
> compiling kernels on, back in those days.

Kernels are now bigger than the two RK05s taken together, let alone
the 128k or 256k or RAM, I used in 1977 with Sixth Edition.  (Uphill
both ways, too.)

> Seems high time to remove
> the 20-group limit, if anyone's game.

It's easy to just change the define, but that ends up allocating lots
more space on every socket that has had any multicast operations, I
think.  It's probably not too hard to turn that array into a linked
list, simlar to the v6 code.

> Bill: does that buy you anything, if other OSes have a similar limit?

He's using v6, so no, because that already uses a linked list.

-- 
        Greg Troxel <gdt@ir.bbn.com>