You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2020. It is now read-only.
Currently Iris supports only group messaging primitives. Although this works for many scenarios, there is a specific use case which is made quite hard and expensive by it. And that is custom resource management.
When an application wishes to use its own custom logic for managing some specific resources, it usually entails an origin doing a search for candidates, and those candidates then contacting the origin out of band for/with the resource. This out of band addressing currently requires the origin to form a unique cluster where it is the only participant, to allow remote nodes to find it.
Two specific scenarios come to mind:
In the case of the decentralized raytracer, when a user node wishes the have a model rendered, it needs to find idle workers (broadcast or publish), but then also needs to distribute the model to those workers and have the workers respond to the correct "job assigner". This would require a tunnel from the workers to the origin... but how to find the origin?
In the case of the a workflow system, an originating node issues a search into the system for destinations which contain a combination of resources needed. But then those need to respond to the searcher specifically.
The question is how to achieve this, without making it too easy for users to abuse the concept and introduce single points of failure? Or whether the issue raised could be solved without giving access to direct addresses?
The text was updated successfully, but these errors were encountered:
Issue #37 is a prerequisite for this.
Currently Iris supports only group messaging primitives. Although this works for many scenarios, there is a specific use case which is made quite hard and expensive by it. And that is custom resource management.
When an application wishes to use its own custom logic for managing some specific resources, it usually entails an origin doing a search for candidates, and those candidates then contacting the origin out of band for/with the resource. This out of band addressing currently requires the origin to form a unique cluster where it is the only participant, to allow remote nodes to find it.
Two specific scenarios come to mind:
The question is how to achieve this, without making it too easy for users to abuse the concept and introduce single points of failure? Or whether the issue raised could be solved without giving access to direct addresses?
The text was updated successfully, but these errors were encountered: