Server Connections: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
As of this writing, the ParaView client makes a single ParaView server connection at the beginning of a session, and closes the connection when the client exits (which causes the server to exit in turn).  To support current and future requirements, the ParaQ client needs to implement a more flexible and robust model for making and breaking connections to the ParaView server, as outlined in [[Crash Test Dummies]].
== Overview ==


Currently, the ParaView Server Manager API contains a number of design assumptions based on the one-client-makes-one-connection model that will need to be updated to support multiple connections.  As an example, vtkProcessModule has static member functions GetProcessModule() and SetProcessModule() that provide access to a single global process module instance.  This has the effect of making vtkProcessModule a singleton, since these global accessors are used throughout the API.
ParaView3 introduces new capabilities for making-and-breaking client/server connections.  In particular, it improves the user experience by making it possible to provide a graphical user interface for server connections, versus the command-line interface of previous ParaView versions.  See [[Server Connection Dialog]] for a graphical user interface design.  This document covers the requirements and implementation details for making connections.


<em>Note: vtkProcessModule already encapsulates support for multiple servers. This support should be extended to handle multiple servers and connections. vtkProcessModule should still be a singleton. </em>
== Connection Types ==


To hide these assumptions and provide the UI layer with a clean abstraction for making-and-breaking server connections, the class "pqServer" has been created.  Static member functions of pqServer act as factory functions for creating server connections, and return an instance of pqServer when a connection is successful. Clients use pqServer methods to interact with the server, and delete the pqServer instance to close the connection. Currently, only one instance of pqServer may be created at-a-time, but it is assumed that this requirement will be relaxed as the PSM API evolves.   ParaQ client code should use the accessor methods of a valid pqServer instance for all access to process module, server manager, and render modules.
ParaView must support several different types of connection between client and server:
 
* Builtin - the client process "connects" to its own "builtin" PV server.
* Remote/Forward/No Startup - the client connects to an already-running PV server.
* Remote/Forward/With Startup - the client starts a PV server, then connects to it.
* Remote/Reverse/No Startup - the client waits for a PV server to connect to it.
* Remote/Reverse/With Startup - the client starts a PV server, then waits for the server to connect to it.
 
== Networking Protocols ==
 
Connections between client and server are normally made using unencrypted TCP/IP networking, but provisions should be made for other possibilities - in particular, [[Secure Connections]] via SSL.
 
== Startup Mechanisms ==
 
When the client "starts" a server for either forward or reverse connections, it must be able to handle a wide variety of situations:
 
* Starting the server directly on the local host.
* Starting the server via a user-configurable script on the local host.
* Starting the server directly on a remote host via ssh.
* Starting the server via a user-configurable script on a remote host, via ssh.

Revision as of 20:10, 22 June 2006

Overview

ParaView3 introduces new capabilities for making-and-breaking client/server connections. In particular, it improves the user experience by making it possible to provide a graphical user interface for server connections, versus the command-line interface of previous ParaView versions. See Server Connection Dialog for a graphical user interface design. This document covers the requirements and implementation details for making connections.

Connection Types

ParaView must support several different types of connection between client and server:

  • Builtin - the client process "connects" to its own "builtin" PV server.
  • Remote/Forward/No Startup - the client connects to an already-running PV server.
  • Remote/Forward/With Startup - the client starts a PV server, then connects to it.
  • Remote/Reverse/No Startup - the client waits for a PV server to connect to it.
  • Remote/Reverse/With Startup - the client starts a PV server, then waits for the server to connect to it.

Networking Protocols

Connections between client and server are normally made using unencrypted TCP/IP networking, but provisions should be made for other possibilities - in particular, Secure Connections via SSL.

Startup Mechanisms

When the client "starts" a server for either forward or reverse connections, it must be able to handle a wide variety of situations:

  • Starting the server directly on the local host.
  • Starting the server via a user-configurable script on the local host.
  • Starting the server directly on a remote host via ssh.
  • Starting the server via a user-configurable script on a remote host, via ssh.
Retrieved from "http://www.paraview.org/ParaView/index.php?title=Server_Connections&oldid=2096"