--fqIB0bRxfTYxTb/F
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 29, 2005 at 10:20:19AM -0400, Greg Troxel wrote:
>   It does that EACH time it gets a request. So if we have ten different=
=20
>   groups, we have ten different sockets.
>=20
> Probably OK until you hit the file descriptor limit.

Well, it seems very wasteful of resources. :-)

>   Is it reasonable to have the same socket join ten different multicast=
=20
>   groups? I _think_ that would be the easiest thing to do, but wanted to=
=20
>   check.
>=20
> 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.
>=20
> In v6, there seems to be an unbounded linked list of joined groups, so
> any sane number of services should be ok.

Great! For v6, SLP joins groups based on a hash of the service name (like=
=20
I muttered), so a host with a lot of services on it could be in many=20
groups.

For v4, there is only one multicast address, so v4 won't have that=20
problem.

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

Yeah, the group name wouldn't get us much. And the processing code just=20
needs to know the packet contents, nothing of the address.

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

Cool.

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

Easily-extended is fine. And when the program's working right, 20 should=20
probably be more than enough for normal use.

Take care,

Bill

--fqIB0bRxfTYxTb/F
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCclq2Wz+3JHUci9cRAgb+AJ4260Q/S1xtLzKERxOUzDDDKKOfAACfbDGw
T7c5IEyKFnn8b/Il8yECip0=
=N0d2
-----END PGP SIGNATURE-----

--fqIB0bRxfTYxTb/F--