Server Connections: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
 
(7 intermediate revisions by 2 users not shown)
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.


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.
== 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.
 
... as a generalization, we likely want to allow the user to specify any arbitrary command-line for starting a server.
 
One case we have to have is a way to start client and a specified number of servers, connect them and load a specified set of files from the server file system using a simple command line or shell script.
 
=== Authentication ===
 
When starting the server on remote hosts via ssh, it will be necessary for the user to provide authentication first.  Using standard ssh command-line prompts to do this would be impractical, since it would not integrate well with the ParaView client's graphical user interface.  There are a number of workarounds:
 
* Posix ssh clients
** OpenSSH - the SSH_ASKPASS environment variable can be used to specify an executable that will be used to prompt the user for a password.  Although this executable is a separate process, its look-and-feel can match that of the ParaView client.
* Windows ssh clients - we assume that they can be started via a command-line, and that they will provide a GUI prompt, but that needs to be confirmed.
** Putty - opens a window and prompts the user for a password using a terminal-style interface.
** F-Secure -

Latest revision as of 10:58, 29 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.

... as a generalization, we likely want to allow the user to specify any arbitrary command-line for starting a server.

One case we have to have is a way to start client and a specified number of servers, connect them and load a specified set of files from the server file system using a simple command line or shell script.

Authentication

When starting the server on remote hosts via ssh, it will be necessary for the user to provide authentication first. Using standard ssh command-line prompts to do this would be impractical, since it would not integrate well with the ParaView client's graphical user interface. There are a number of workarounds:

  • Posix ssh clients
    • OpenSSH - the SSH_ASKPASS environment variable can be used to specify an executable that will be used to prompt the user for a password. Although this executable is a separate process, its look-and-feel can match that of the ParaView client.
  • Windows ssh clients - we assume that they can be started via a command-line, and that they will provide a GUI prompt, but that needs to be confirmed.
    • Putty - opens a window and prompts the user for a password using a terminal-style interface.
    • F-Secure -
Retrieved from "http://www.paraview.org/ParaView/index.php?title=Server_Connections&oldid=4310"