On 2013-05-31 11:12, Mariusz Janiak wrote: > 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?
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. > >>> 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. ;) > >>> 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? Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
