Kai Moritz wrote: > Hello again, > > I wonder, if the following idea is practicable: > > TDMA ensures, that every packet is sent stricly after the other. So, if > an distributed application would save a serial number in an broadcast > message, it would be able to verify, that it really will send the next > broadcast in a series, if it could check the counter just before the > packet is put on the wire. For that, a hook would be neccessary, that > informs the application just before the packet is put on the wire, so > that the application could check, if another broadcast message has > arrived after it has scheduled it's own one for sending. In this case > the application could abort the send and consider the informations of > that broadcast message, before attemping to send a new one...
Sounds very specific too me. What about this approach: lay out the TDMA slots in a way that there is enough time for an application to first check for incoming packets and then issue its own outgoing data to the TDMA scheduler so that it will be considered for the same TDMA cycle. Or is your communication structure not organisable in this way? Note that you will need some "safety" margin in a temporal manner between packet arrival and a potential transmission cancellation anyhow. Transmitting a packet in case no data arrived may require a bit more processing time, but this should not be a significant difference. On the other hand, interfering with the TDMA transmission process adds further jitter to this critical path. Jan
signature.asc
Description: OpenPGP digital signature
