--4Kq+wHeKEs1nwG7z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 29, 2005 at 10:26:56AM -0700, Jonathan Stone wrote:
>=20
> In message <rmi3bt9is0s.fsf@fnord.ir.bbn.com>,
> >Greg Troxel writes:
> >  It does that EACH time it gets a request. So if we have ten different=
=20
> >  groups, we have ten different sockets.
> >
> >Probably OK until you hit the file descriptor limit.


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

I know that usrreq calls use mbufs. Could it be that there is (was, was=20
intended) a call to get the number of groups, and that thus the response=20
had to fit in an mbuf? Just guessing...

> Kernels are now bigger than physical RAM on the machines I was
> compiling kernels on, back in those days. Seems high time to remove
> the 20-group limit, if anyone's game.
>=20
> Bill: does that buy you anything, if other OSes have a similar limit?

For v4, not really. But then again for v4, SLP only uses one multicast=20
address.

v6 is more the concern as it joins mcast groups based on that hash of the=
=20
service name. So we could in principle be in 65536 groups (though that=20
would be a VERY busy server supporting a diverse network).

Since I expect the number of service types (which is what the group=20
membership is based on) will be fairly static, if an admin can change the=
=20
limit (like it seems one can for Linux) or the limit is really high (us),=
=20
then that's ok.

Take care,

Bill

--4Kq+wHeKEs1nwG7z
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCco1EWz+3JHUci9cRAgSTAJ9/6OqHyLl/Ytuf1T8vG/tqH6MnLQCeK+e8
R6mVD4e/CE25NNYlBdFn/Ng=
=DWUr
-----END PGP SIGNATURE-----

--4Kq+wHeKEs1nwG7z--