Subscribing to a PULL request is only necessary if the user wants to get provided data. Because the subscription was hidden, the user had no chance to get that data...
Comment by Chirag (which is correct):
"PD Pull Request is answered immediately without checking whether that comId (of the requesting packet ‘Pr’) was subscribed or not. The standard says that that is not how it should be.
The current scenario is that, as long as any PD is subscribed by the device, this device will answer all the ‘Pr’ requests because simply the UDP port is open and so it can receive PDs! We noticed this recently only because a recent commit removed the internal subscription of TRDP_STATISTICS_PULL_COMID. Because of this implicit subscription in the tlc_init(), all the later ‘Pr’ were automatically answered. Now that this subscription is removed, there is still the issue that subscribing to any PD on application level will result into answering all consequent requests. The ‘Pr’ answering code needs to be put after checking the subscription queue."
-> see new Ticket #216
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Comment by Chirag (which is correct):
"PD Pull Request is answered immediately without checking whether that comId (of the requesting packet ‘Pr’) was subscribed or not. The standard says that that is not how it should be.
The current scenario is that, as long as any PD is subscribed by the device, this device will answer all the ‘Pr’ requests because simply the UDP port is open and so it can receive PDs! We noticed this recently only because a recent commit removed the internal subscription of TRDP_STATISTICS_PULL_COMID. Because of this implicit subscription in the tlc_init(), all the later ‘Pr’ were automatically answered. Now that this subscription is removed, there is still the issue that subscribing to any PD on application level will result into answering all consequent requests. The ‘Pr’ answering code needs to be put after checking the subscription queue."
-> see new Ticket #216