Subject: [magma] getsockopt for full-state source filter API

From: [email-masked]
Date: Sun, 12 Jan 2003 17:23:08 +0000

Dear Dave, Bill & Bob,

    Last week, I wrote an email to you about my linux based IGMPv3 
implementation where I  have implemented setsockopt() and getsockopt() as the 
API for storing and  retrieving multicast source filter information for full-
state API applications. Since I had my kernel patch and userAPI examples as 
file attachments in that email I am not sure if the email may have been 
filtered out.

    In your multicast source filter API draft <draft-ietf-magma-msf-api-
03.txt>, the guidelines for full-state API suggested use of ioctls as it said 
getsockopt could not be used to retrieve multicast filter information. I have 
implemented full-state API using setsockopt & getsockopt. For my latest patch 
implementing all the API's as per current draft as well as my rather 
proprietary structs for getsockopt & setsockopt implementation, please visit: 
http://home.attbi.com/~v.kulkarni/igmpv3/igmpv3.html

    After exchanging a few emails with Linux kernel maintainters for network 
code, I realised that they too preferred getsockopt & setsockopt for full-
state API over ioctls. While it's just a tiny matter about implementation I & 
a few maintainers on the linux community feel that the API uniformity achieved 
by doing so may be desirable. As authors of the draft, we would like to have 
your approval in this regard.

While I am currrrently working on using standard struct ip_msfilter with 
set/getsockopt and cleaning out some of the gore from the above implementaion, 
I breifly describe a proposal for using getsockopt for full-state API.

SETSOCKOPT:

int fd                      /* socket fd */
struct ip_msfilter *msf     /* full-state multicast source filter */
int len                     /* Size of msf IP_MSFILTER_SIZE(n) */

To join group with source filter:
setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, msf, len);
To modify filter:
setsockopt(fd, IPPROTO_IP, IP_SET_SOURCE_FILTER, msf, len);
To drop:
setsockopt(fd, IPPROTO_IP, IP_DROP_MEMBERSHIP, msf, len);

setsockopt supports struct ip_msfilter in addition to other forms of it's use 
as mentioned in your draft.

GETSOCKOPT:
To retrieve filter information with getsockopt:
int fd                       /* socket fd */
struct ip_msfilter *gmsf     /* retrieve full-state multicast filter here*/
int glen                      /* Size of gmsf with source buffer */

* Allocate gmsf with a reasonable guess on the size of source filter (say 0)
* Set imsf_multiaddr & imsf_interface as desired. 
* Set imsf_numsrc to number of source addresses the source list field can hold 
(in this case 0)
getsockopt(fd, IPPROTO_IP, IP_GET_SOURCE_FILTER, gmsf, &glen);

Return values: 
If fail: -1, errno set to approp cause of failure (-EFAULT, etc)
IF successful: return 0. (or alternately 0 or positive value specifying number 
of sources recorded in kernel)
Further,
glen set to actual size in kernel. ie IP_MSFILTER_SIZE(k) if kernel has k 
sources recorded and needed to get all information from kernel.
gmsf->imsf_numsrc set to number of source address returned.
gmsf->imsf_fmode set to filter mode.
gmsf->imsf_slist has as many sources as kernel could copy ie: min (imsf_numsrc 
as passed to socket call, actual list size as stored in kernel)

I would very much appreciate your feedback/comments about this. 

Thanks & Best Regards,
Vinay Kulkarni

The past is history. The future is a mystery. But this moment is a gift. 
That's why it's called 'present'
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: [email-masked]
Date: Mon, 13 Jan 2003 15:45:52 +0000

After looking at BSD kernel code, it appears that BSD issue boils down to BSD
kernel doing a copyin() on the getsockopt optval pointer to user data.

The getsockopt primitive that first appeared in BSD4.2 does define pointer to
optval buffer to be passed down into the kernel. From that point, it's is for
the kernel to copyin and read user data and then copyout relevant information. I
am not an expert at BSD kernel code but I felt this was doable. Please correct
me if I am wrong, maybe BSD experts can comment/correct me.

Besides, BSD4.4 and earlier dont support IGMPv3 by birth so you will have to
patch it anyways. And if you are going to do that, can you not walk the extra
mile to fix getsockopt too? The same may apply to other OS's that overlooked
using full capability of API's.

I believe that the decision point to go with getsockopt or stay with ioctl is
now. Like Toerless mentioned, if we are even considering the possibility of
revising the decisions later, it may be more difficult when a ton of applicaiton
code has already been generated using ioctls and books written about it. I
believe we are trading off a desirable method for compatibility with a old
version of a particular OS. Maybe we should abondon all use of getsockopt as it
did was not there 4.2BSD eve.

With Best Regards,
Vinay Kulkarni

The past is history. The future is a mystery. But this moment is a gift. That's
why it's called 'present'.
> It would of course be nice to have this reasoning at least in an
> appendix of the MSFAPI draft so that future generations are still
> aware of the reason for the compromises taken - helps especially those
> folks who in a couple of years want to revise the decisions.
> 
> Cheers
> 	Toerless
> 
> On Sun, Jan 12, 2003 at 02:07:45PM -0800, Bill Fenner wrote:
> > 
> > >state API over ioctls.
> > This is a Linux implementation detail.  The implementation of getsockopt()
> > in BSD 4.4 and earlier did not pass the user data to the protocol layer,
> > so the only information the protocol layer can be guaranteed to have
> > is the optname (e.g. IP_ADD_MEMBERSHIP).  Thus, a portable API cannot
> > assume that the data in the buffer the user passed to getsockopt() is
> > available to the protocol.
> > 
> > We considered using setsockopt() for setting the full-state, and ioctl()
> > for retrieving the full-state, but decided that it would be better to
> > have a consistent set/get API.  Since getsockopt()'s limitations required
> > us to use ioctl() for get, we use ioctl() for set too.
> > 
> >   Bill

---

From: [email-masked]
Date: Mon, 13 Jan 2003 15:45:52 +0000

With Best Regards,
Vinay Kulkarni

---

From: Bill Fenner <[email-masked]>
Date: Mon, 13 Jan 2003 08:22:36 -0800

>After looking at BSD kernel code, it appears that BSD issue boils down to
>BSD kernel doing a copyin() on the getsockopt optval pointer to user data.

No, that's the easy part.  The issue is changing the calling conventions
of the pr_ctloutput() routines, that's why the change in FreeBSD was over
1000 lines.  And the real issue is not BSD per se, other than that's
where the socket interface came from.

Multicast has enough deployment problems, without adding an additional
barrier to developing the API.  I still think that you and David are
ignoring the possibility that the developer that is writing the IGMPv3
API would not have permission to modify the getsockopt handler, and
that e.g. a design committee would have to approve changes to how
getsockopt works and that multicast isn't a good enough reason.

I'll say again: we evaluated these tradeoffs already, and decided against
specifying that getsockopt has to change.  I don't think that anything
has changed to change the balance of that decision.  You want to barf when
you see that we use ioctl()?  We're in the same boat, I want to barf too,
but I still think it's the right tradeoff.

  Bill

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 13 Jan 2003 10:30:15 -0800

> -----Original Message-----
> From: Bill Fenner [mailto:[email-masked]]
> Sent: Sunday, January 12, 2003 2:08 PM
> To: [email-masked]
> Cc: Dave Thaler; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: getsockopt for full-state source filter API
> 

I'll second what Bill says.  The getsockopt buffer is not available in
other OS's besides BSD too.  Hence getsockopt could be used for a Linux-
specific API, but it is not appropriate for use in the portable api
specified in the draft.

-Dave