If ConfD were to send “as fast as possible” to the fastest subscriber, it would have to queue notifications for the slower subscribers internally, and that queue could grow without bounds. Instead it sends the notifications “one at a time”, i.e. it doesn’t pick up a new notification from the application socket until the previous one has been sent to all subscribers, effectively pushing the queue to the socket buffers and eventually to the notification-sending application, which will block in confd_notification_send() / confd_notification_send_path() if it continuously sends notifications faster than the slowest subscriber reads them.
I.e. the throughput will indeed be limited by the slowest subscriber, as you observed. To handle the pathological case of a subscriber that remains connected but doesn’t actually read its notifications, the confd.conf parameter /confdConfig/netconf/writeTimeout should be useful.
As the question is stated, not much I think.
There is no “signalling” as such - the connections are flow-controlled by the standard SSH/TCP mechanisms, meaning that a sender can’t send unless the receiver reads - and the reciever can read whenever there is something available.
Yes, and it is “asynchronous” in so far as there is no handshake or the like at the NETCONF application layer. (But of course the SSH/TCP flow control has “handshaking” of sorts, based on available space in the receiver’s buffers.)
Per above, there is no queue.
I’m not really familiar with the new establish-subscription, but I believe the notification sending uses the same mechanism.