MultipleServerConnections: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
 
No edit summary
Line 1: Line 1:
==Overview==
==Overview==


In ParaView, ServerManager works with VTK objects on 3 entities: '''DataServer''', '''RenderServer''' or '''Client'''. Once connections are established between ''N'' RenderServer nodes and ''first N'' DataServer nodes, they are bound together. Thus, DataServer and RenderServer always go together. Now, we want to enable the client to connect to multiple such '''''DataServer-RenderServer''''' groups. This document discusses the design for enabling the same.
In ParaView, ServerManager works with VTK objects on 3 entities: '''DataServer''', '''RenderServer''' or '''Client'''. Once connections are established between ''N'' RenderServer nodes and ''first N'' DataServer nodes, they are bound together. Thus, DataServer and RenderServer always go together. Now, we want to enable the client to connect to multiple such '''''DataServer-RenderServer''''' groups (which we will call '''''ServerCouple'''''). This document discusses the design for enabling the same. For sake of simplicity, we can treat the Client as a special kind of ''ServerCouple''.
 
==Assumptions==
* For now, we assume that each ''ServerCouple'' is vanilla i.e. it cannot have any VTK objects created on it, when the client connects to it. This assumption ensures that there are no '''object ID''' conflicts between the Client and the ServerCouple.
 
==Requirements==
* It must be possible for ServerManager to specify which ''ServerCouple'' it wants to access.
 
==Design==

Revision as of 15:49, 17 October 2005

Overview

In ParaView, ServerManager works with VTK objects on 3 entities: DataServer, RenderServer or Client. Once connections are established between N RenderServer nodes and first N DataServer nodes, they are bound together. Thus, DataServer and RenderServer always go together. Now, we want to enable the client to connect to multiple such DataServer-RenderServer groups (which we will call ServerCouple). This document discusses the design for enabling the same. For sake of simplicity, we can treat the Client as a special kind of ServerCouple.

Assumptions

  • For now, we assume that each ServerCouple is vanilla i.e. it cannot have any VTK objects created on it, when the client connects to it. This assumption ensures that there are no object ID conflicts between the Client and the ServerCouple.

Requirements

  • It must be possible for ServerManager to specify which ServerCouple it wants to access.

Design