From owner-freebsd-current Mon Oct 7 19:35:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA23397 for current-outgoing; Mon, 7 Oct 1996 19:35:37 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA23340; Mon, 7 Oct 1996 19:35:01 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.6/8.7.3) with SMTP id WAA03085; Mon, 7 Oct 1996 22:32:51 -0400 (EDT) Message-Id: <199610080232.WAA03085@whizzo.transsys.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: wollman@lcs.mit.edu (Garrett Wollman), ache@nagual.ru, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org, current@FreeBSD.org, bde@zeta.org.au From: "Louis A. Mamakos" Subject: Re: I plan to change random() for -current (was Re: rand() and random()) References: <199610071850.LAA14614@phaeton.artisoft.com> In-reply-to: Your message of "Mon, 07 Oct 1996 11:50:42 PDT." <199610071850.LAA14614@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 07 Oct 1996 22:32:51 -0400 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I have to agree with Terry here about "fixing" rand()/srand(). For better or worse, there are expections on the implementation of these functions in a standard C libarary. For instance, in a recent Internet Draft of a protocol specification for multicast routing protocol (draft-ietf-idmr-pim-sm-spec-05.txt): > 3.7 Hash Function > > The hash function is used by all routers within a domain, to map > a group to one of the C-RPs from the RP-Set. For a particular > group, G, the hash function uses only those C-RPs whose Group- > prefix covers G. The algorithm takes as input the group address, > and the addresses of the Candidate RPs, and gives as output one > RP address to be used. > > The protocol requires that all routers hash to the same RP > within a domain (except for transients). The following hash > function must be used in each router: > > > 1 For each candidate RP address Ci in the Candidate-RP- > Set, whose Group-prefix covers G, compute a value: > Value(G,M,Ci) = > 1103515245 ((1103515245 (G&M)+12345) XOR Ci)+ 12345 mod 2^31 > where M is a hash-mask included in RP-Set messages. > This hash-mask allows a small number of > consecutive groups (e.g., 4) to always hash to the same RP. > For instance, hierarchically-encoded data can be sent on > consecutive group addresses to get the same delay and > fate-sharing characteristics. > > In standard C, this corresponds to: > > srand(G & M); > srand(rand() ^ Ci); > value = rand(); > > 2 The candidate with the highest resulting value is then > chosen as the RP for that group, and its identity and hash > value are stored with the entry created. > > Ties between C-RPs having the same hash value, are broken > in advantage of the highest address. > > The hash function algorithm is invoked by a DR, upon reception > of a packet, or IGMP Host-Membership-Report, for a group, for > which the DR has no entry. It is invoked by any router that has > (*,*,RP) state when a packet is received for which there is no > corresponding (S,G) or (*,G) entry. Furthermore, the hash > function is invoked by all routers upon receiving a Join/Prune > message with WC-bit set. I'm not defending the use here, but if we can avoid breaking assumptions and having an "incompatible" implementation, we ought to. If it looks like a duck, and walks like a duck, it should quack like one too. Louis Mamakos