[PATCH] multicast support, take 2

[Garrett Rooney <ro...@electricjellyfish.net>]

ok, here's a revised patch for adding some multicast support to APR.

since the last patch i posted i've moved to an extended socket option 
interface (since that's what people seemed to want).  i've also added 
support for APR_SO_MC_REUSEADDR, which tries to mask the differences in 
operating system support for multiple programs binding to the same 
multicast port.  on some systems all sockets involved in such a thing 
must use SO_REUSEPORT, while on others you just need to set 
SO_REUSEADDR.  in this case, APR_SO_MC_REUSEADDR sets SO_REUSEPORT if 
it's present, and SO_REUSEADDR in any event.

again, this is almost completely untested, unix only, and i'm mainly 
looking for comments on the interface (both the extended socket options 
interface and the APR_SO_MC_REUSEADDR idea).

-garrett

Re: [PATCH] multicast support, take 2

[Garrett Rooney <ro...@electricjellyfish.net>]

On Wednesday, April 16, 2003, at 02:28 AM, Justin Erenkrantz wrote:

> --On Tuesday, April 15, 2003 9:25 PM -0400 Garrett Rooney 
> <ro...@electricjellyfish.net> wrote:
>
>> again, this is almost completely untested, unix only, and i'm mainly 
>> looking
>> for comments on the interface (both the extended socket options 
>> interface
>> and the APR_SO_MC_REUSEADDR idea).
>
> Looks good on cursory review.
>
> As a nitpick, why not APR_SO_EXT_GROUP_JOIN and apr_socket_join_arg_t 
> instead? Realizing, of course, APR_SO_MC_REUSEADDR needs the MC to 
> avoid the collision (and has the implicit REUSEPORT if available), but 
> do we really have to propagate that MC_ elsewhere?  I'm ambivalent on 
> it, but the mc_'s sort of strike me funny.  Not a big deal either 
> way...  -- justin

no especially good reason.  i wanted to make the various multicast 
specific options obviously multicast specific, but it's not vital that 
we do so (hell, the underlying socket options don't bother to).

-garrett

Re: [PATCH] multicast support, take 2

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Tuesday, April 15, 2003 9:25 PM -0400 Garrett Rooney 
<ro...@electricjellyfish.net> wrote:

> again, this is almost completely untested, unix only, and i'm mainly looking
> for comments on the interface (both the extended socket options interface
> and the APR_SO_MC_REUSEADDR idea).

Looks good on cursory review.

As a nitpick, why not APR_SO_EXT_GROUP_JOIN and apr_socket_join_arg_t instead? 
Realizing, of course, APR_SO_MC_REUSEADDR needs the MC to avoid the collision 
(and has the implicit REUSEPORT if available), but do we really have to 
propagate that MC_ elsewhere?  I'm ambivalent on it, but the mc_'s sort of 
strike me funny.  Not a big deal either way...  -- justin