Add the concept of session's to remus.

[robertmaynard]

Currently all workers that exist inside remus are based on a stateless model. The presumption is that any worker of a given type will be able to fulfill any job given. But lets say that we have a really large model that we transmit to a worker, which from we might want to generate numerous meshes. If we have multiple workers that can fulfill the given requirements we would have to send the entire model each time.

I want to introduce the concept of a session to remus. A session would allow a client to bind instances of workers to accept multiple jobs, and would not give jobs to workers outside the session, even if they match all the requirements.

A session would not be a 1 to 1 binding of clients to workers, but would support a 1 to N binding which allows clients to decide how many workers are part of a session.

Currently if somebody wants to create a session using remus they need to do it in a 2 set process. The first job that a client sends, and which a worker accepts is merely a reference to a session Id. After that the worker disconnects from the server, and reconnects with the session id as the tag for its job requirements. Now a client sends all job requirements using that tag, and we have a poor man's version of a session

[robertmaynard]

@vibraphone I think this summarizes the session issue, but I haven't come up with a clean way for a client to request a worker to bind to a session. Do you have an idea on how you think the client interface would look like?

[vibraphone]

I think that extending the tag concept to include multiple values (i.e., make tag() a set of strings), one of which was a session key would work. The set equality operator would then be used and only workers and requirements with the same set of tags would be paired.

The only issue then is bootstrapping. The use cases are initiating a new session (where arguably the worker ought to specify the session ID) and restoring an existing session (where the session ID is specified). Perhaps providing methods like this:

class Worker
{
public:
  bool addTag(const std::string&); // signal server of updated JobRequirements
  bool delTag(const std::string&); // signal server of updated JobRequirements
  std::set<std::string> tags();
  // ...
};

would work? I assume clients can ask for the tags of all the workers of a given MeshIOType. If not, that would also be required. But I'm pretty sure I've seen that.