Thread: [RTnet-developers] multicast support
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers
|
From: Amine El h. <am...@an...> - 2005-05-24 12:10:33
|
I need to use rtnet for audio & video streaming , so i want to add support for multicasting to rtnet. Now im trying to understand the working of mutlicasting in linux kernel, and i look for the way to port it to rtnet. So if you have any propositon to do that , please let me know. Amine |
|
From: Jan K. <jan...@we...> - 2005-05-24 18:58:44
|
Amine El hedadi schrieb: > I need to use rtnet for audio & video streaming , so i want to add support for > multicasting to rtnet. > Now im trying to understand the working of mutlicasting in linux kernel, and i > look for the way to port it to rtnet. > So if you have any propositon to do that , please let me know. > Beyond the aspect of how to manage rtskbs (RTnet's real-time packet buffers) for which I already posted a mail thread link, you should certainly first start with multicast at Ethernet level. First, you need support in at least one driver. Pick one and extend (or re-enable) its multicast features. Watch out for potentially required hard real-time synchronisation means between transmission/reception handlers and multicast manipulation functions. Feel free to ask what to use or how certain things work inside the driver. Next, it's likely useful to add the required API to the packet socket interface (stack/packet/af_packet.c). That API has to provide means for registering to and detaching from a multicast group at Ethernet protocol level. Check Linux man pages etc. for documentation. Later, the integration in RTnet's UDP/IP stack can be addressed. Here, the question needs to be answered how to map the multicast IP address on Ethernet MAC addresses. Not sure right now how this happens in normal networks, but I guess a static configuration is likely the easiest way for a first approach in RTnet. Looking forward to further discussions! I'm also interested in learning more about multicast implemenation and potential hard real-time issues. Jan |
|
From: Jan K. <jan...@we...> - 2005-05-25 07:43:43
|
Jan Kiszka schrieb: > ... > Later, the integration in RTnet's UDP/IP stack can be addressed. Here, > the question needs to be answered how to map the multicast IP address on > Ethernet MAC addresses. Not sure right now how this happens in normal > networks, but I guess a static configuration is likely the easiest way > for a first approach in RTnet. > And if I had thought about this a second longer, I would have remembered that RTnet's routing system already provides all what's required for that static mapping. Jan |
|
From: Amine El h. <am...@an...> - 2005-05-25 14:03:30
|
think you Jan for this explanations. Now im traying to build a mark of linux multicast working. So to port it to rtnet , i will need some informations about RTNET archetecture . that will help to do it cleanly and correctly. Amine On Tuesday 24 May 2005 20:58, you wrote: > Amine El hedadi schrieb: > > I need to use rtnet for audio & video streaming , so i want to add > > support for multicasting to rtnet. > > Now im trying to understand the working of mutlicasting in linux kernel, > > and i look for the way to port it to rtnet. > > So if you have any propositon to do that , please let me know. > > Beyond the aspect of how to manage rtskbs (RTnet's real-time packet > buffers) for which I already posted a mail thread link, you should > certainly first start with multicast at Ethernet level. First, you need > support in at least one driver. Pick one and extend (or re-enable) its > multicast features. Watch out for potentially required hard real-time > synchronisation means between transmission/reception handlers and > multicast manipulation functions. Feel free to ask what to use or how > certain things work inside the driver. > > Next, it's likely useful to add the required API to the packet socket > interface (stack/packet/af_packet.c). That API has to provide means for > registering to and detaching from a multicast group at Ethernet protocol > level. Check Linux man pages etc. for documentation. > > Later, the integration in RTnet's UDP/IP stack can be addressed. Here, > the question needs to be answered how to map the multicast IP address on > Ethernet MAC addresses. Not sure right now how this happens in normal > networks, but I guess a static configuration is likely the easiest way > for a first approach in RTnet. > > Looking forward to further discussions! I'm also interested in learning > more about multicast implemenation and potential hard real-time issues. > > Jan |
|
From: Amine El h. <am...@an...> - 2005-06-01 09:36:10
|
Hi It is possible to use Linux timer in RTNET framework? Linux use them for multicast support. Amine. |
|
From: Jan K. <ki...@rt...> - 2005-06-01 10:31:05
|
Amine El hedadi wrote: > Hi > It is possible to use Linux timer in RTNET framework? > Linux use them for multicast support. > Generally not - as long as not just device setup, reconfiguration, or shutdown is involved. You would have to use equivalent RTAI features. What are these timers precisely used for? Right now, I cannot imaging what kind multicast related job needs timing. Shouldn't it "just" be programming some additional MAC addresses (or address hash values) the card shall listen to? Or are those timers required for higher layers? Jan |
|
From: Zhang Y. <y.z...@st...> - 2005-06-01 10:40:49
|
Linux timer is not real-time, but rtai timer is ok. See the rati tasklet module. Yuchen > -----Original Message----- > From: rtn...@li... > [mailto:rtn...@li...] On > Behalf Of Amine El hedadi > Sent: Wednesday, June 01, 2005 11:40 AM > To: rtn...@li... > Subject: Re: [RTnet-developers] multicast support > > Hi > It is possible to use Linux timer in RTNET framework? > Linux use them for multicast support. > > Amine. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into > your own Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > RTnet-developers mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-developers > |
|
From: Amine El h. <am...@an...> - 2005-06-01 11:09:34
|
Linux use timer in muticast to excute periodically a function to keep session between switch & computer whitch need multicast flux , so it use one timer by multicast connection(IGMP protocol). this work not need a real time behaviurs, so why I have asked about using the same timer in RTNET framework. I can use real periodic task but I don't need real time behaviors in this case, may be rt task with low priority. Amine > Amine El hedadi wrote: > > Hi > > It is possible to use Linux timer in RTNET framework? > > Linux use them for multicast support. > > Generally not - as long as not just device setup, reconfiguration, or > shutdown is involved. You would have to use equivalent RTAI features. > > What are these timers precisely used for? Right now, I cannot imaging > what kind multicast related job needs timing. Shouldn't it "just" be > programming some additional MAC addresses (or address hash values) the > card shall listen to? Or are those timers required for higher layers? > > Jan > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > RTnet-developers mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-developers |
|
From: Jan K. <ki...@rt...> - 2005-06-01 11:55:34
|
Amine El hedadi wrote: > Linux use timer in muticast to excute periodically a function to keep session > between switch & computer whitch need multicast flux , so it use one timer by > multicast connection(IGMP protocol). this work not need a real time > behaviurs, so why I have asked about using the same timer in RTNET framework. > I can use real periodic task but I don't need real time behaviors in this > case, may be rt task with low priority. > I see, my knowledge about multicast has just been proven to be rather limited :). The point with a Linux timer is not that it is too unreliable for this task (BTW, about what period dimensions are we talking here?), the problem is that you cannot issue a packet from non-RT Linux context (IRQ, tasklet, process, whatever). So you need at least a low prio real-time task (one step above Linux, see how RTcfg works WRT timers e.g.) to transmit this keep-alive stuff. I guess you have to transmit those packets only if no other traffic was present on the specific multicast channel (MAC address), haven't you? Isn't it possible to code this feature into the application? I think it knows best when it last received or transmitted some data. Or am I just missing some important characteristics of the IGMP protocol? In any case, I think the IGMP part, which seems to be required when it comes to IP multicasting, is part of step 2, while the first step should be to get the low level multicast support (Ethernet layer) working. Or does this appear to be too tightly coupled for you? Jan |
|
From: Amine El h. <am...@an...> - 2005-06-03 16:13:47
|
Hi It is possible to get rtnet_device pointer form rtsocket pointer. for example struct rtnet_device *rtdev= xxxxx(struct rtsocket sk); I can't find any way to do that Other things : what mean the rtdm_device fileds : " device_name" "peripheral_name" "driver_name" Can'I use any on eof them with the function get_dev_by_name . think Amine |
|
From: Jan K. <ki...@rt...> - 2005-06-03 16:34:48
|
Amine El hedadi wrote: > Hi > > It is possible to get rtnet_device pointer form rtsocket pointer. > for example struct rtnet_device *rtdev= xxxxx(struct rtsocket sk); > I can't find any way to do that There is no static relation between a socket and some network device. A socket can be used to transmit or receive packets from different devices. You can change this situation for UDP/IP by binding a socket to a local IP (i.e. device) or by connecting with some remote IP (i.e. preselecting the output device). But as IPs and routes may change, there is no fixed pointer stored in the socket structure even in this cases. Intead, packets are analysed on reception if the took the right path. And the route is still calculated right before packet transmission. > Other things : > what mean the rtdm_device fileds : > " device_name" That field is only used for named devices, like serial drivers or any special devices like the TDMA discipline interface. It has no meaning for protocol drivers like RTnet's UDP/IP and packet socket implementations. > "peripheral_name" > "driver_name" > Pure informational stuff, only used for browsing RTDM devices via /proc so far. > Can'I use any on eof them with the function get_dev_by_name . > Nope, get_dev_by_name resolves names like "rteth0" or "rtlo". What are you actually planning? Likely there is a different way to achieve it. Jan |
|
From: Amine El h. <am...@an...> - 2005-06-06 15:55:33
|
hi >What are you actually planning? Likely there is a different way to >achieve it TO send an IGMP request to join a multicast goup ,the only information i had is the rt_socket ,and i need to send directly the igmp packet without passing by the ip level , that mean to use directly the xmit_start function ,to use it i need rtnet_device pointer. you see the problem i had ? So I have resolved the problem by adding a new function in "rtdev.c", its role is to get rtnet_device by local_ip adress.it work well. The only constrain that we must specify the local ip adress when using multicast. |
|
From: Jan K. <ki...@rt...> - 2005-06-14 09:05:45
|
Hi Amine, sorry for the late reply. >>What are you actually planning? Likely there is a different way to >>achieve it > > TO send an IGMP request to join a multicast goup ,the only information i had > is the rt_socket ,and i need to send directly the igmp packet without passing > by the ip level , that mean to use directly the xmit_start function ,to use > it i need rtnet_device pointer. you see the problem i had ? > So I have resolved the problem by adding a new function in "rtdev.c", its > role is to get rtnet_device by local_ip adress.it work well. The only > constrain that we must specify the local ip adress when using multicast. > What about rt_ip_route_output()? Doesn't it exactly do what you need? It fills a dest_route structure which then contains a pointer to the output rtdev. Take a look at rt_udp_sendmsg() for a usage example. Jan |
|
From: Amine El h. <am...@an...> - 2005-06-14 13:29:59
|
Hi jan; > What about rt_ip_route_output()? Doesn't it exactly do what you need? It > fills a dest_route structure which then contains a pointer to the output > rtdev. Take a look at rt_udp_sendmsg() for a usage example. That's ok, rt_ip_route_output() give a pointer to the output rtdev , but only in the case when we add the multicast adress to route table : # rtroute add 239.0.0.2 01:00:5e:00:00:01 dev rteth0 , that work well, But in the case of multicat, we can calculate the mac address from the IP address without using routing table. So i have added a conditions test before the call of the "rt_ip_route_output()" in udp_sendmsg function if the dist address is multicast i calculate the mac adresse and i locate the rtdev by the local address (saddr). So nowday Im able to recive and send mulicast packets with rtnet .Im testing it now and i will send you a first realise of my patch soon. PS : i have only enabled the multicast support for the two NICs ,8139too et e100. Amine > Hi Amine, > > sorry for the late reply. > > >>What are you actually planning? Likely there is a different way to > >>achieve it > > > > TO send an IGMP request to join a multicast goup ,the only information i > > had is the rt_socket ,and i need to send directly the igmp packet without > > passing by the ip level , that mean to use directly the xmit_start > > function ,to use it i need rtnet_device pointer. you see the problem i > > had ? > > So I have resolved the problem by adding a new function in "rtdev.c", its > > role is to get rtnet_device by local_ip adress.it work well. The only > > constrain that we must specify the local ip adress when using multicast. > > > Jan > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput a projector? How fast can you ride your desk chair down the office > luge track? If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > RTnet-developers mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-developers |
|
From: Jan K. <ki...@rt...> - 2005-06-14 13:47:34
|
Amine El hedadi wrote: > Hi jan; > > >>What about rt_ip_route_output()? Doesn't it exactly do what you need? It >>fills a dest_route structure which then contains a pointer to the output >>rtdev. Take a look at rt_udp_sendmsg() for a usage example. > > That's ok, rt_ip_route_output() give a pointer to the output rtdev , but > only in the case when we add the multicast adress to route table : > # rtroute add 239.0.0.2 01:00:5e:00:00:01 dev rteth0 , that work well, > But in the case of multicat, we can calculate the mac address from the IP > address without using routing table. > So i have added a conditions test before the call of the > "rt_ip_route_output()" in udp_sendmsg function > if the dist address is multicast i calculate the mac adresse and i locate the > rtdev by the local address (saddr). > Well, I would prefer some solution that actually creates such a routing table entry. Not yet sure how this may look like. Either we have to distribute this setup via RTcfg to the stations or some socket ioctl or sockopt has to be introduced to create the routing table entry on demand. The advantage: this avoids the additional check in the transmission path for both multicast and unicast packets. > So nowday Im able to recive and send mulicast packets with rtnet .Im testing > it now and i will send you a first realise of my patch soon. > PS : i have only enabled the multicast support for the two NICs ,8139too et > e100. > Great, looking forward! Jan |
|
From: <am...@an...> - 2005-06-23 14:52:26
|
Hi I want to test rtnet-0.8.2 with fusion ,can you tell me where can I download the fusion 0.7.1 : 0.7.4 , because i have only find the fusion 0.7 & fusion 0.8 in the RTAI web site. think for your help. |
Thanks for helping keep SourceForge clean.
X