The socket structure & igmpv3

2000-03-30 Thread Wilbert de Graaf
Hello all, I'm working on an implementation of the IGMPv3 protocol in the Net/3 stack, and several questions popped up. The first one is about the socket structure. The IGMPv3 protocol allows a process to set (ip)source filters, which is a list of ip addresses of sources which indicates the pro

Refresh a list that could be used

2000-04-11 Thread Wilbert de Graaf
Hi,   As part of an IGMPv3 implementation on FreeBSD I had to add a list to a datastructure (in_multi). This list can be set by users (using ioctl) and be replaced later. While replacing this list, there is the possibility (ad1) of a concurrent reader (the process when an incoming packet has

Getting the plain void* through the generic ioctl processing

2000-06-28 Thread Wilbert de Graaf
Could anybody advise me on this: For an implementation of IGMPv3, I had to extend the socket api following the draft(s). I had to add two ioctl commands: SIO_GET_MULTICAST_FILTER and SIO_SET_MULTICAST_FILTER. The argument is a structure that has a variable size. FreeBSD uses some macros, and the

#include question: requires

2000-07-12 Thread Wilbert de Graaf
Maybe obvious to some of you, but I had to define two new structures (as described in an ietf draft) in . This in order to be able to support igmpv3 / multicast source filters. Anyway, these structures require 'struct sockaddr_storage' which is defined in . When I compiled the code, it stopped si

Re: #include question: requires

2000-07-13 Thread Wilbert de Graaf
Alfred Perlstein wrote: > > > > somewhere in the top of . I want to verify if this is indeed > > the best way to solve it ? > > No, the proper solution is to do a forward struct declaration like so: > > struct something; > > struct bigger_something { > struct something foo; > } As we

Re: #include question: requires

2000-07-13 Thread Wilbert de Graaf
Hi Alfred, > you might as well unconditionally include sys/socket.h and let it's > internal #ifndef take care of that problem. you're right and i'll change it > I'm not sure why you don't just make your own new header file for > this struct unless you're adding to an existing structure in > so