Hi, > >>> 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? > > Hmm, don't think so. And it looks like this field is write-only in > RTnet's RTcfg implementations as well. So it was likely added to the > spec with something else in mind that I do not remember anymore and also > never implemented.
Ok, I skip this field. > > > >>> 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? > > I'm afraid this is not that precisely specified. The current > implementation should handle and "early" ack as well, resetting the > config offset accordingly and resuming transmission from there. So let's > assume this was also specified. ;) Ok, it sounds reasonable. > > > >>> 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. > > Well, there could be something like "rtcfg <dev> monitor > [event,event,...]" with one event being "node-failure". Then you will > need to define and implement a corresponding RTcfg-config IOCTL that > implements the actual blocking of the caller and its wakeup on the > specified events in the kernel. The return code of the IOCTL or some > additional data structure could provide information about the event that > caused a wakeup. Well, that's a first, rough description if such an > interface. What would be important is to match it against an actual use > case, i.e. some script or application that will actually call "rtcfg > monitor". Otherwise, we risk designing something that no one would use > in the end. What do you have in mind here? I though rather about application api (xenomai native, posix). So, in the first step, I should implement ioctl blocking service and something like event-info structure. Then I prepare example containing relevant use case. The "rtcfg <dev> monito [event,event,...]" is last on my TODO list. What do you think about it? Mariusz > Jan ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
