It does that EACH time it gets a request. So if we have ten different 
  groups, we have ten different sockets.

Probably OK until you hit the file descriptor limit.

  Is it reasonable to have the same socket join ten different multicast 
  groups? I _think_ that would be the easiest thing to do, but wanted to 
  check.

You almost certainly know this, but for v4 the answer would be 10 yes,
21 no.  You'd have to keep multiple sockets, and move on to a new one
when getting ETOOMANYREFS.  I ran into this when writing a multicast
test program on NetBSD ~1.1 that needed to join 2000 groups.

In v6, there seems to be an unbounded linked list of joined groups, so
any sane number of services should be ok.

One benefit of multiple sockets is that one can map the fd to the
group that was joined.  I don't know SLP, but given the notion of
hashing service name to a group, the group probably isn't a useful key
and the packets would be processed without needing to know the
arriving group.  Or perhaps there is a v6 equivalent of RCV_DSTADDR;
I'm not quite sure if IPV6_PKTINFO does this.

Barring needing to know the group of incoming packets and possible
efficiency issues with large lists of joined groups, I don't see any
issues on NetBSD.

It's my impression from quagga that the v6 sockets api is fairly
consistent across operating systems.  I wouldn't be shocked to see a
limit on # of joined groups per socket, though.  For v4, Linux
defaults to 20, but can it be extended via /proc or similar.

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