Round-robin mechanism leads to lost requests

[joelguittet]

Hello @dashersw

I'm building a project with multiple requesters and responders.

All responders in my system are not able to answer all the topics. For example:

• "responder1" is able to respond to "topic1" and "topic2"
• "responder2" is able to respond to "topic2" and "topic3"
• "requester1" requests "topic1"
• "requester2" requests "topic2"
• "requester3" requests "topic3"

Requesters and responders advertisement fields "requests" and "respondsTo" are filled accordingly.

I notice the following issue:

• all requesters connects to all responders (OK, this is the actual wanted purpose I think)
• when "requester1" sends a requests "topic1", because of the round-robin mechanism used, the requests is done sometimes to "responder1" and the response is received (OK) and sometimes to "responder2" which is not aware of the "topic1" and do not respond at all (KO).

=> When a request is sent by a requester, the selected responder sock should be checked to verify the responder is able to answer to the wanted topic, by checking advertisement "respondsTo" array.

Additionally, to avoid unused connections, I think it is better to match advertisement "requests" and "respondsTo" arrays when a node is discovered. In my example above, "requester1" do not need to connect to "responder2". Not verified at this moment, but probably the same remark can be done for pub/sub instances.

Actually I'm trying to make a patch and I can propose a Pull Request if it is working.

Joel

EDIT: I have seen https://github.com/dashersw/cote/issues/165 about the subset mechanism, but it's a pitty to have subset=respondsTo...

[dashersw]

Hello Joel, this is in fact the intended mechanism on cote — one needs to use keys to differentiate between services. By default any component can connect to and respond to any other component. The main purpose is to keep it zero-configuration. When some responders would like to specialize on certain topics, which would require configuration, they need to differentiate themselves with keys. This creates a nice segmentation of services based on a theme, rather than individual messages.

requests is currently only used for documentation purposes, and respondsTo is currently only used in the Sockend component, as a simple mechanism to provide some frontend-facing messages and some backend-only messages.

[joelguittet]

Hello @dashersw

Tell me if I'm wrong (I have not implemented keys in the C library yet but maybe it will be a great motivation to do it), but if the services uses different keys, they will not be able to connect each other because they will not be able to discover each other. Isn't it ?

So let's make the following scenario:

• "responder1" is able to respond to "topic1" and "topic2" and uses key "key1"
• "responder2" is able to respond to "topic2" and "topic3" and uses key "key2"
• "requester1" requests "topic1" and uses key "key1" ==> OK it's working and requests are always forwarded to "responder1" because "requester1" is connected only with "responder1" due to the usage of the key.
• "requester2" requests "topic2". Which key should be used there ? If using "key1" then the requests are always send to "requester1" and if using "key2" then the requests are always send to "requester2" ==> No Round-Robin at all.

You said:

By default any component can connect to and respond to any other component. The main purpose is to keep it zero-configuration.

This is suitable if all responders can respond to all requests topics only. On the other side, thinking to a strange combination of keys is at the opposite of "zero-configuration". But maybe a specific way to handle this case is possible and I'm happy if you have an example of that usage?

I have created a Pull Request at https://github.com/dashersw/cote/pull/241. As proposed in the first message of this issue, Round-Robin is performed only on responders which are able to answer based on respondsTo. Indeed this is done at message level.

Joel

[dashersw]

I believe it would be very confusing from a software design / architecture perspective that responder 1 and responder 2 have overlapping responsibilities. Ideally keys fully segregate messages and responsibilities — if r1 responds to t1 and t2, r2 shouldn't respond to either t1 or t2. If there's an overlapping concern, I would suggest 3 keys — r1-t1 pair, r2-t2 pair, and r3-t3 pair. This way you can individually scale all of these services.

[joelguittet]

Well, in this case why implementing the round-robin mechanism ? From a scaling/redundancy of services it make sense. Several services for example can provide the current system time, it's not really a problem.

In the application I'm currently building, I'm not able to define several keys, because my services are instantiated dynamically and it's not possible to know which keys will be used. All services can't answer all the requests, and most of the services do not overlap, but some few services do. That's maybe a specific use case I have, not sure.

If anybody is reading this thread can also give another point of view / use case it's welcome of course :-)