Subject: Re: multicast daemon design
To: Greg Troxel <gdt@ir.bbn.com>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 04/29/2005 11:39:24
In message <rmir7gth44q.fsf@fnord.ir.bbn.com>,
Greg Troxel writes:

>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().

Oh, drat. I originally wrote "ip_output", then my fingers corrected it
to "ip_output()". it is of course ip_setmpotions() in ip_output.c
With that correctino, I think we're  seeing, and saying, the same thing.



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

A linked list is simple, but that'd be a very inefficient and
inelegant thing to do, if Bill really wants modest-to-large numbers.
Something like per-process fd managmenet, maybe.


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


Bill seems to be interested in portability, and having OpenSLP
continue to work on other OSes, so I naturally assumed he'd have to
not break OpenSLP over IPv4. OTOH I may be wrong.