MultipleServerConnections: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
(→Design) |
(→Design) |
||
| (4 intermediate revisions by the same user not shown) | |||
| 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 (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''. | 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. We discuss the changes to ProcessModule to enable multiple connections. For sake of simplicity, we can treat the Client as a special kind of ''ServerCouple''. | ||
==Assumptions== | ==Assumptions== | ||
| Line 14: | Line 14: | ||
* Just like each Proxy keeps this->Servers which tells it what servers it's created on, should it also keep this->ServerCouples? Thus giving the proxy the knowledge about its location? | * Just like each Proxy keeps this->Servers which tells it what servers it's created on, should it also keep this->ServerCouples? Thus giving the proxy the knowledge about its location? | ||
* SendStream() will take the ServerCouple Id as well. To send the stream to multiple servercouples, the caller must call SendStream multiple times with different ServerCouple each time. For this to work, Client must be treated as a special ServerCouple. Otherwise, (simply extending current ParaView design), Client will be a part of each ServerCouple and any stream could be sent to client on multiple ServerCouples, which is absurd! | * SendStream() will take the ServerCouple Id as well. To send the stream to multiple servercouples, the caller must call SendStream multiple times with different ServerCouple each time. For this to work, Client must be treated as a special ServerCouple. Otherwise, (simply extending current ParaView design), Client will be a part of each ServerCouple and any stream could be sent to client on multiple ServerCouples, which is absurd! | ||
* May be, for sake of backwards compatibility, we can have a overloaded SendStream() with prototype same as current ParaView, which would imply send to all active ServerCouples (except Client). Client will be included only if vtkProcessModule::CLIENT flag is set in the server flags provided. | |||
* API for gather information will be as GatherInformation(ServerCoupleId, Servers). Thus, allowing the caller to GatherInformation from ServerCouple of his choice as well as Server of his choice. | |||
==Issues== | |||
Here I list the issues I encountered while implementing the new process modules. | |||
* IceT RenderModules require SocketController/RenderSocketController. | |||
* ProgressHandler uses a SocketController---this is really bad.....on whcih connection do we send the progress event? | |||
==Additional Links== | |||
* [[GatherInformation]] How GatherInformation works. | |||
Latest revision as of 14:27, 4 November 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. We discuss the changes to ProcessModule to enable multiple connections. 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.
- It must be possible to query the ProcessModule to determine if a ServerCouple connection is active.
Design
- Multiple ServerCouples can exists only on the Client side. ProcessModules on the server worry about just 1 ServerCouple.
- Each ServerCouple is assigned a Unique Id. The ID cannot merely be the index of the ServerCouple connection since this would make it difficult to detect case when a ServerCouple disconnects and another one connects. Hence, we assure that when a ServerCouple disconnects, its ID is not reused until max(vtkIdType) (or whatever datatype we use for the Id) ServerCouples connect with the client.
- Just like each Proxy keeps this->Servers which tells it what servers it's created on, should it also keep this->ServerCouples? Thus giving the proxy the knowledge about its location?
- SendStream() will take the ServerCouple Id as well. To send the stream to multiple servercouples, the caller must call SendStream multiple times with different ServerCouple each time. For this to work, Client must be treated as a special ServerCouple. Otherwise, (simply extending current ParaView design), Client will be a part of each ServerCouple and any stream could be sent to client on multiple ServerCouples, which is absurd!
- May be, for sake of backwards compatibility, we can have a overloaded SendStream() with prototype same as current ParaView, which would imply send to all active ServerCouples (except Client). Client will be included only if vtkProcessModule::CLIENT flag is set in the server flags provided.
- API for gather information will be as GatherInformation(ServerCoupleId, Servers). Thus, allowing the caller to GatherInformation from ServerCouple of his choice as well as Server of his choice.
Issues
Here I list the issues I encountered while implementing the new process modules.
- IceT RenderModules require SocketController/RenderSocketController.
- ProgressHandler uses a SocketController---this is really bad.....on whcih connection do we send the progress event?
Additional Links
- GatherInformation How GatherInformation works.
