Hi Jan, > > > > 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?
You mean, waiting for what? Let summarize negotiation procedure: 1. Server send Config Stage 1. 2. New client send New Announce. 3. Other clients send Reply Announce -- then new client update its tables (eg. ARP). 4. Server send Config State 2 -- with Active station field (I don't need it so far) 5. Server send Config 2 frames, client send ACK. 6. When Stage 2 will be finished, client send ready frame -- from now it is able to communicate with other nodes, if some node hasn't sent Reply Announce is not present in ARP table so write operation will fail. We know if node is ready from bit 1 of Flag field of Reply Announcement frame or from Ready frame. Have I missed something? > > 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. On this stage I don't have any particular inconsistency on my mind. I only try follow of RTnet specification. As far as I understand, client should send ACK after specified number of stage 2 configuration frames given by burs rate (value negotiated with server). For example, if burst rate is set to 2 and after first frame client detect inconsistent data, it should wait for one more frame and, then send ACK witch proper Acknowledge Length or should send ack just after detect inconsistency? > > 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. Ok. > > > > 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. Ok, I thought so. > > > > 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. Ok, I have missed this part. > > > > 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. Do you have something special in mind. This information is present in the system, the only problem is to export it to application. If you don't mind I could try to take care of it, with a little help from your side. Best, Mariusz > PS: Be warned, I've designed and implemented RTcfg a pretty long while > ago and may no longer be 100% accurate with my answers. ;) Ad PS. I'll be careful. ------------------------------------------------------------------------------ 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
