Round-robin mechanism leads to lost requests about cote HOT 4 OPEN

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.

from cote.

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 #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

from cote.

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.

from cote.

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 :-)

from cote.