From dev-return-13477-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Dec 31 04:07:26 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 60144 invoked from network); 31 Dec 2004 04:07:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 31 Dec 2004 04:07:26 -0000 Received: (qmail 20907 invoked by uid 500); 31 Dec 2004 04:07:25 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 20624 invoked by uid 500); 31 Dec 2004 04:07:24 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 20610 invoked by uid 99); 31 Dec 2004 04:07:24 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Date: Fri, 31 Dec 2004 04:07:17 +0000 From: Colm MacCarthaigh To: Paul Querna Cc: dev@apr.apache.org Subject: Re: [PATCH] Multicast Support Message-ID: <20041231040717.GA25245@castlerea.stdlib.net.> Reply-To: colm@stdlib.net References: <41D49EE6.1060702@force-elite.com> <20041231013644.GA24492@castlerea.stdlib.net.> <41D4CBAF.6030001@force-elite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41D4CBAF.6030001@force-elite.com> User-Agent: Mutt/1.3.28i X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Thu, Dec 30, 2004 at 07:46:55PM -0800, Paul Querna wrote: > I haven't done anything with SSM, but I agree it would be nice to have a > single API if this is a feature that will be widely used. It's already in wide use in some spheres, it's the only form of multicast that has realistic DoS prevention (with ASM, arbitrary multicast users can trivially join and flood a group id). I'll have at least on APR-based SSM implementation ready in a few months anyway, for widescale virus signature updating. > >Passing "iface" as a sockaddr is not going to be portable, the API's on > >some systems (Win32 and Linux, using IPv6) for example prefer interface > >names as the references. Using a string might be better, as it's > >possible to convert strings to interface numbers ( if_nametoindex() ) and > >sockaddr's ( inet_addr() ). > > I made is a sockaddr, because I believed that to be the most portable. Same here, and then I ran into problems ... > Interface names are per-OS. (eg win32, linux, freebsd, and solaris are > all different). This means if I want cross platform or even cross > machine configuration, it must not use the interface name, but a network > address. (Cross Machine: eg, some machines have Intel Cards, others have > Broadcom, in FreeBSD these have different interface names.) > > I welcome a better solution... :) I resorted to user specifying either something like "eth0" or "1.1.1.1" depending on their platform. One very ugly solution, but about all that is portable. Even this isn't foolproof, there is no self-consistent way between IPv4 and IPv6 to do this on win32. For the *nix's, some consistency can be got by abandoning the ip_mreq API and using the group_req one instead - but this is flaky, on *BSD you need to running a bleeding-edge KAME stack and on Linux you need to manually define the structures and defines, because the system headers are broken (oh and you need to be running a pretty recent 2.6 kernel). But ultimately, the group_req API is far superiour technically. > I thought that for any OS that prefers the interface name/number, we can > always map the sockaddr to that interface pretty easily. Win32 with IPv6 was my stumbling block with that approach :/ But it's probably best ignored for these purposes. I've tested on Linux anyway, the send/recv apps work fine in IPv6, recv works fine in IPv4, there's a kink in my system for sending IPv4 - but I havn't had a chance to look at it yet, I doubt it's anything in the multicast code though, since sending packets should be identical for unicast and multicast. I'll be back in my dev environment on Tuesday, where I can subject it to the full rigours of our multicast test-lab and feed-back more, I'll submit some group_req-based SSM code at some point too (unless someone beats me to it). -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net