Hi Amine,
hi ,
Here the first realise of patch for multicast support in RTnet , This realise
support :
* IGMP V2
I have only adapt the NIC drivers for :
*RT_8139too : Tested
*RT_eepro100 : Not Tested
-HOW TO USE IT ;
1- Apply the patch to rtnet : (0.8.1 - 0.8.2 - 0.8.3)
2- Patch the NIC driver
3- Execute the autogen.sh scritp to generate a new configure file. (a new
config option will added "--enable-multicast" )
4-execute configure "./configure --with-rtai=<RTAI-DIR>
--enable-multicast "
Now in your application if you want to receive multicast packets you must use
setsockopt " RT_IP_ADD_MEMBERSHIP " , to stop the reception of multicast
packet you can use "RT_IP_DROP_MEMBERSHIP"
Don't forget when sending multicast packet to specify the local IP adress,
don't use INADDR_ANY (Only way I've fount to locate the device) .
for more detail about use of multicast in RTNET please see the sample attached
to this mail.
I hope if any body can test this patch ,and if you have any idea to improve
it.
Im working now on a new realize of this patch , I will add :
* the possiblity to modify the TLL value( new IOCTL in the socketopt).
* IGMP V1 Support.
* A random response to the query request (IGMP V1 & V2).
Great! Thanks for the patch, it looks very good. So far I only
cross-read parts of it. Let's see if you got the implications of this
multicast patch correctly:
o Joining or leaving a multicast group can be performed from
non-real-time context. Are those IOCTLs (or should they once become
socket options?) compatible with the linux multicast interface, or
does that one work differently?
o Routing is as simple as finding the NIC a socket is bound to via its
source address.
o It take a periodic rt-task to send some "keep-alive" igmp message
every 500 ms with low priority (how long may this message be delayed
until switches start to drop the membership?). Is this also required
in case I'm connected to hubs or an unmanaged switches?
The patch is very unintrusive to the core, especially when
CONFIG_RTNET_MULTICAST is not selected. Therefore, I will see if we can
merge into SVN soon. But I have two tiny criticisms:
o The handling of RT_IP_ADD_MEMBERSHIP and RT_IP_DROP_MEMBERSHIP should
check for the correct context (non-RT), and it should be moved to the
IP subsystem (rt_ip_ioctl or even rt_ip_setsockopt).
o Please review your driver patches if changing multicast addresses
does not clash with the real-time operation of the NIC. At least
the multicast set funtion of the rt_8139 does not seem to use the
correct locking functions yet and uses printks within critical
sections (note that it has not been used in parallel with RT-parts of
the driver so far). Let me know if you need some hints in this
respect.
Thanks again,
Jan
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
