Hi, Jan,
these days I am thinking of how to integrate the Firewire iso into RTnet
stack. To make the work more general/not-firewire-specific, I got an idea to
introduce the channel based broadcasting, where the Firewire iso is one
implementation.
In other words: Multicasting? Or where is the difference?
In channel based broadcasting, active node should choose one channel to put
its packet on fly, while the passive node tunes itself (in hardware or in
software) to that certain channel to receive the packet. One node can listen
to multiple channels at the same time, but may only use one channel to
"radio" its packet. Compared with traditional point-to-point communication,
like on Ethernet, the channel based broadcasting fits better within the
distributed control system. Because in distributed control system, almost
any communication is time-triggered, e.g. the encoder->controller->actuator
in position control. Also some communication is one to many, so really like
a radio, the channel based broadcasting can be used here without any extra
overhead.
Ethernet cards also support this scenario to some degree by offering to register multiple MAC addresses or MAC hash keys on which the cards may listen for incoming packets (additionally to broadcasts and its own MAC). Very comfortable and easy to schedule are cards which support MAC lists. Unfortunately, some cheaper models only support those hash keys, making live harder as you have to detect key collisions in order to estimate system load due to unwanted packets (working on real-time can be hard...).
So much for the Ethernet low-level world. Firewire seems to have a clean model by allowing to filter those channels in hardware, doesn't it? And how is the periodical transmission managed in Firewire? Does the driver/stack have to interact for each isochronous packet or only if anything else than a linear memory stream is transmitted. I.e. what will you have to do for transmitting always the some memory region (e.g. some process states), and how to synchronise any access to this memory?
To introduce the channel based broadcasting, one or more extra modules need
to be created in the stack. One is the API module, which is to provide to the application a set of high
level primitives and hide all the internal details. (This could be done by
making an extension to the RTDM module.) Second is the Packet Management module, which is to (de)multiplex the
messages. There may be several processes on one node, (the process may be
called Server here since they are actively sending some message), hence the
PM module is responsible to put all the messages into one packet with an
index. Also in the receiving side, the PM module should also demultiplex the
incoming packet according to the index.
It may be asked that where to do the allocation and subscription of
channels. Well, this could be done in PM module also. But since distributed
control system is not that flexible, and normally not need to be, so this
work can also be done during the offline configuration phase.
Well, for me the need for a new API depends on what extra features Firewire may give us compared to multicasting. With respect to packet oriented multicasting, IP already comes with such an interface, it "only" has to be added to the RTnet core. If Firewire also manages periodical re-transmissions of memory regions in hardware, one may think about a fitting API again.
Of course, we also need a hardware/fieldbus-specific module to implement all
the high-level primitives. For the hardware, as far as I know, Firewire,
CAN, even Ethernet can be a choice. In my opinion, Firewire fits best, both
on the latency and the convenience (the tuning to multiple channels is
supported in Firewire chip).
Stepping one layer lower from IP, the Packet Socket API of Linux also provides some interface for joining and leaving multicast groups - independent of the transmission media. Again it's packet oriented, so it has to be checked if this matches the Firewire model.
Ok, so far, this is my rough idea. Any correction and addition is welcome-:).
It is definitely an interesting topic, especially as many high-layer protocols like RTPS can also make use of multicast / broadcast channel features. Multicast is on our roadmap for quite a while now. But it has been postponed due to some still open design question I also discussed in this mail:
http://www.mail-archive.com/rtnet-users%40lists.sourceforge.net/msg00454.html
Shared skbs would be required if we want to have multiple local receivers of multicasted packets or broadcast streams. Whatever solution might be found, it will likely increase the complexity of the reception path compared to the current version. If we deny this as a first approach, things would certainly be easier. However, it may significantly degrade the usability of RTnet in non-trivial application scenarios.
Jan
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
