[zeromq-dev] PGM and sending interface

[Steven McCoy]

On 6 January 2016 at 04:47, Jim Hague <jim.hague at acm.org> wrote:

> I've not read RFC3678 before, but after a quick look it seems to me that
> the
> RFC isn't concerned with the socket binding, and hence the source address
> used.
>
>
Yes, the source of a multicast is specified usually by the multicast
address and interface, however with IP aliasing that interface
specification is effectively broken.  Note that an address is insufficient
as IPv6 local link addresses are scoped to the interface, thus it must be
interface index + address.


> As a minimal disturbance to the existing API I'm trying adding an alias
> index
> to t pgm_interface_req_t. That in turn means that the alias index must be
> available from pgm_getaddrinfo(), so I'm changing the group_source_req
> items
> in pgm_addrinfo_t to a pgm_group_source_req which adds the alias index. I
> guess an alternative would be to change pgm_bind3() (or add a pgm_bind4())
> where recv and send would be specified via an address. I guess that would
> mean
> adding receive and send addresses to the result from pgm_getaddrinfo().
>
>
The direction appears to take the address from pgm_getaddrinfo() and place
into a new member variable of pgm_interface_req_t:

struct pgm_interface_req_t {
  uint32_t ir_interface; struct sockaddr_storage ir_address;  uint32_t
ir_scope_id;
}; Although now with the address the explicit scope identifier is not
required, thus it simply becomes: struct pgm_interface_req_t {
  uint32_t ir_interface; struct sockaddr_storage ir_address;}; There should
be some form of precedence for this, I usually refer to mDNSResponder code
for platform peculiarities. Using the alias index is going to be subject to
race conditions when interfaces change and I'd rather try to avoid that. --
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160106/65323848/attachment.htm>