-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Many sub and one pub #25
Comments
Hi, I had a look and it is to be expected: you can get lucky and have all 70 subscribers get it (I did, so I know it can happen), but there is no guarantee whatsoever. The reason is firstly the way the two programs work, and secondly the chosen quality-of-service settings: The first part, the way they work is the following: the publisher waits until the discovery data indicates there is a subscriber (really just until there is a change in the number of discovered subscribers), then it writes one sample and terminates. Because all the processes independently discover each other, it may be that it publishes that sample when it has discovered just one subscriber, some of them, or all of them. While that is entirely timing dependent, in practice it seems likely that starting the publisher after the subscribers were started gives you a good chance that it will discover many of them in time, simply because starting the publisher triggers the discovery. Another factor could be that the first call to The second part has to do with the QoS: this is a volatile (durability QoS kind) topic/writer/reader, and so the one sample published only goes to the readers discovered at the time of writing [1]. Addressing this type of problem is what the "durability" QoS setting is for. If, instead of There is one problem with this approach though: the writer must remain in existence, so you can't terminate the process immediately. If you change the QoS this way and add a sleep — e.g., of 1s — after the call to This is nice, of course, but you should not have to keep the process and the writer in existence (it would mean you could never stop it as long as another reader might show up ...), and that is why DDS has a The real strength of DDS lies in this particular mode, "transient" data is the concept that really helps for building fault-tolerant, extensible systems where processes can come and go. "Transient-local" is nice, but it can't really help when components can fail/crash. However, it is also vastly simpler to implement than "transient" data. While full support for transient data is very much in sight for Cyclone, at the moment it is not yet supported. And so, though transient-local is but a poor alternative, it is the only option at the moment [5]. Does this clear up things or did I only make it more confusing? 🤔 [1] It may even be dropped by the reader if it hasn't yet discovered the writer, that's a grey area. |
Thank you so much for explanation! |
And one more question, if I launch 70 sub, then one pub, sometimes all receive, but if I launch 100 sub, then one pub, there is few sub receive the message, what's the reason? |
I guess the more subscribers, the more time it takes to the discovery. It all runs in parallel, so it is conceivable that with 70 it can still make it, but that with 100 it has almost all of them halfway through the discovery. 'Tis but a guess ... there is a hard-to-read tracing format that would tell you more, but I'm quite certain the overhead of tracing to a text file will significantly affect this timing. As to making sure all subs receive the message while using "volatile" data, the only option is to wait longer between P.S. All that is perfectly fine, but it does make for a much tighter coupling between the subscribers and the publisher than I personally would be happy with. |
I think u right, DDS should be not so tight coupling. Thank you for your careful explanation!!! |
Hi,
I test the example HelloworldPublisher, if over 70 sub, but just one pub, many sub will not receive the message, what's the reason for this? and is there place to configure this
The text was updated successfully, but these errors were encountered: