Subject: RE: about joining multiple group addresses on a single socket

From: Mike Luby <[email-masked]>
Date: Thu, 16 Mar 2000 15:13:48 -0800

Wilbert,
With our technology (see the Asynchronous Layered Coding protocol
instantiation draft in the RMT working group submitted to this IETF) we do
join multiple groups to receive information that is relevant to one
particular application.  This has turned out to be more efficient and useful
in Windows than using a separate socket for each group.  The idea is that
all the packets from multiple groups are aggregated into a single decoder to
recover a single object (object = generic file, video clip, word document
...).  Thus, we do find it useful.
Mike Luby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Wilbert de Graaf
Sent: Thursday, March 16, 2000 11:55 AM
To: idmr
Subject: SSM: about joining multiple group addresses on a single socket

Hugh, Brad,

I'm in doubt about  4.1, the remark about recvfrom(). I'm trying to think
why you would want to join a single socket to multiple group addresses. The
only reason to perform successive joins on a single socket for me has been
to join multiple interfaces, but not group addresses. I just wonder if it is
really necessary to perform demultiplexing on a socket in an application
using destination addresses.  Could somebody tell me about applications that
need this, or refer to an archived discussion about this ?

The first sentence in chapter 8, paragraph 2, ends with "even for an SSM
destination address G". I think you can strip that part since in the
beginning of the line you already narrowed down to SSM datagrams. And the
only SSM datagrams that come into another domain carry an SSM destination
address right ?

Regards, Wilbert

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 16 Mar 2000 19:35:32 -0800 (PST)

Wilbert,

My understanding is that at least one of the streaming media players
receives multiple data streams on a single socket. So I don't think
the ability to receive multiple channels (or groups) on a single
socket is useless.  I'd agree that it is not strictly necessary, but
it appears to be convenient for some application writers (like Mike).

> only SSM datagrams that come into another domain carry an SSM destination

Thanks; you're right.  A result of a last-minute rephrasing of this
paragraph.  I struck the clause.

-Hugh

---

From: Wilbert de Graaf <[email-masked]>
Date: Fri, 17 Mar 2000 17:48:31 -0800

> it appears to be convenient for some application writers (like Mike).

Is see. It's clear to me now why this function has be there.

Looking at the draft "Socket Interface Extensions for Multicast Source
Filters" (draft-ietf-idmr-msf-api-00.txt), and although the title doesn't
imply an extension of recvfrom(), it could include this requirement since
the subject itself is quite closely related: ... Probably too much to change
to the socket api at once, but on the other hand, it would save us another
rfc.

- Wilbert

---

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Mar 2000 19:43:18 -0800 (PST)

> to the socket api at once, but on the other hand, it would save us another

You don't need to change recvfrom().  That's what recvmsg() is for.

-Dave