On 2013-05-28 18:05, Mariusz Janiak wrote: > Hi! > > During development of RTcfg layer on uP, a several questions have arisen > because of lack of my understanding of the some RTcfg protocol parts. > > 1. What exactly client should do with content of Active Station field in > stage 2 Initial frame? All the necessary information can be obtained through > a announcement and a ready frames.
Not really. For how many reply should a new client wait after sending out its announcement frame? > > 2. What should happen when a client detect a inconsistent state 2 data > between ack? It should wait for a number of frames given by burst rate or do > something else? What kind of inconsistency do you have in mind? In case a client receives some stage 2 configs it doesn't like, it must not ack it. Rather, it acks what it already received properly. Can be 0 as well. That shall trigger the server to retry the stage 2 configuration from that point on. > > 3. What happen when the flag 0 (request available stage 2 configuration data > from the server) in Flags field in New Announcement frame is not set and the > server has stage 2 data for given client (set in server RTnet configuration > file) The server should assume the client ack'ed all the stage 2 configs despite not having it sent. > > 4. Why Physical Client Address field in Dead Station Frame is 32bytes long? To allow support for physical media that have longer physical addresses than Ethernet. > > And other questions from standard PC implementation (Xenomai): > > 1. Where stage 2 data are stored on client side? How client can get to these > data. It's stored in RTcfg stack only briefly, dropped as soon as you extracted it via the RTcfg command line tool. That tool may dump the data to the console or into a file. See documentation. > > 2. If some station stop responding (stop sending a heartbeats), is there a > way to inform a application that some station is down? Or that the station is > up? The information is exported via /proc on both client and server. Unless I forget something, there is no event signaling mechanism to wait on such an error via the rtcfg tool, e.g. But that would be implementable if required. HTH, Jan PS: Be warned, I've designed and implemented RTcfg a pretty long while ago and may no longer be 100% accurate with my answers. ;)
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
