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: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 14:07:45 -0800

>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