Mulit-Client-Multi-Server Issues

From ParaQ Wiki
Jump to navigationJump to search

Introduction

This page collects all issues and possible solutions for mult-client/multi-server configurations.

ID Uniquification

Issue

  • Note: this discussion includes the SelfID assigned to a proxy as well as the ObjectIDs assigned to the VTK objects the proxy stands for.
  • Every server-side/client-side object is assigned an ID when it is created. The interpretors indentify the object by this ID.
  • When multiple clients are connected to the server, it is essential that all those clients use the same ID for the same object, otherwise it is not possible to identify the object on different clients.
  • When a client is connected to multiple servers, there can't be conflicts between ID for objects on different servers.

Solution

  • Every client keeps multiple interpretors for every connection(both server as well as self connection). Server has only one interpretor.
  • When creating any object, the client requests a unique ID for the object from the server on which the object is being created. For self connection, it assign the object a unique ID by itself.
  • Since there are separate interpretors for different connections, and also since the same object cannot exits on different servers, ID clashes among different server connections are not an issue.
  • Also since client obtains the ID from the server, every client connected to the server can be sure that the ID is unique for all clients connected to that server.

Proxy Manager Registration name Uniquification

Issue

  • Every client has a proxy manager.
  • Every proxy the client creates is registered with the proxy manager giving an unique (group, name).
  • When multiple clients are connected to a server A, any proxy the client creates for objects on server A must have the same (group, name) among all clients connected to that server.
  • Since each client can be connected to multiple servers as well, this (group, name) must be unique among all those servers as well.

Solution

  • ProxyManager no longer uses merely (group, name) tuple to identify proxies.
  • The API for registering a proxy remains same : vtkSMProxyManager::RegisterProxy(group, name, proxy).
  • However the internal datastructure for registration key for the proxy includes (group, name, proxy.SelfID, connectionID), where:
    • group :- group name.
    • name :- proxy name.
    • proxy.SelfID :- The SelfID assigned to the proxy. This ID is server sepecific. All clients connected to the server know exactly which proxy we are talking about when we use this ID.
    • connectionID :- This is the client-side id which the client assigns to the server connection. This connectionID may be different for the same server connection on different clients.
    • Note that proxy.SelfID and connectionID both can be obtained from the proxy itself, hence the RegisterProxy() API remains unchanged.
  • Now, the names no longer need to be unique, since the (proxy.SelfID, connectionID) component of the tuple uniquifies it.
  • vtkSMProxyManager::GetProxy(group, name) becomes legacy API which returns the first proxy found with the given name.
  • vtkSMProxyManager::GetProxy(group, name, proxyID, connectionID) returns a unique proxy.
  • vtkSMProxyManager::GetProxy(proxyID, connectionID) returns a unique proxy.
  • vtkSMProxyManager::GetProxy(group, name, connectionID) returns a list of all proxies with the given group/name on the given connection.