Skip to content
This repository has been archived by the owner on Aug 3, 2020. It is now read-only.

Client bindings: add support for direct messaging (resource management) #38

Open
karalabe opened this issue Jun 5, 2014 · 0 comments
Open

Comments

@karalabe
Copy link
Member

karalabe commented Jun 5, 2014

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:

  • 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?

@karalabe karalabe added this to the v0.4.0 milestone Jun 5, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant