neuray API Programmer's Manual

Bridge client

[Bridge]

Description

The Bridge client is integrated in the application that wishes to use the resources of the remote cluster. The client connects to a single Bridge server. The client does not form a cluster with the Bridge server. The server can be part of a normal cluster of any size, which automatically makes the resources of the entire remote cluster available to the client. The client can be part of a cluster of any size, but the resources of the client-side cluster are used only for local jobs, not when executing jobs using a remote cluster via the Bridge.

See the API component mi::bridge::IBridge_client for a starting point.

See also:

Bridge, Bridge server

Classes

class 
This mixin class provides a default implementation for some of the methods needed by mi::bridge::IClient_job. More...
class 
API component that serves as entry point for the client-side Bridge API. More...
class 
Represents the client-side part of a job that can be executed by the Bridge server. More...
class 
Provides detailed information about the progress of a Bridge job. More...
class 
Abstract interface for bandwidth measurement events. More...
class 
Represents the client side of a Bridge scope. More...
class 
Represents the client side of a Bridge session. More...
class 
Abstract interface for callbacks for session state changes. More...
class 
Represents the client side of a Bridge transaction. More...
class 
Abstract interface for callbacks for asynchronous transaction commit or abort events. More...
class 
Client-side video context that receives and decodes video frames from the corresponding server-side video context. More...
class 
Used to specify a set of elements by name. More...
class 
API component that serves as entry point for the client-side Iray Bridge API. More...
class 
More...
class 
Context for creating Iray Bridge snapshots. More...
class 
Represents the data for a single video frame. More...
class 
Abstract interface to receive video frames produced by the corresponding server-side video context. More...
class 
Base class for Bridge jobs that only update elements without executing anything. More...

Enumerations

enum mi::bridge::Client_job_state{ CLIENT_JOB_DETECTING_CHANGES = 0, CLIENT_JOB_PREPARING = 1, CLIENT_JOB_QUERYING_CACHE_STATUS = 2, CLIENT_JOB_UPLOADING = 3, CLIENT_JOB_PENDING = 4, CLIENT_JOB_DONE = 5, CLIENT_JOB_FORCE_32_BIT = 0xffffffffU}
Job states of Bridge jobs. More...
enum mi::bridge::Client_session_state{ CLIENT_SESSION_CONNECTING, CLIENT_SESSION_CONNECTED, CLIENT_SESSION_PENDING, CLIENT_SESSION_CLOSED}
The different states a client session can be in. More...

Enums

enum mi::bridge::Client_job_state

Job states of Bridge jobs. Execution of Bridge jobs often involves uploads to the server which can take a considerable time. Each Bridge job goes through a sequence of states defined by this enum, starting in the state CLIENT_JOB_DETECTING_CHANGES and then progressing to the next state when some conditions are met until the job execution is done and the job ends up in the state CLIENT_JOB_DONE. States will always progress to the next state in the defined order, but some states might be skipped if there is no work that needs to be done in that state. Note that a lot of work is done in parallel so while the job is still determining which elements that needs to be updated, it will also query the cache status and start uploading data for cache misses, etc.

See also:

mi::bridge::IClient_job_progress::get_state()

Enumerator:

CLIENT_JOB_DETECTING_CHANGES = 0
Detecting which database elements needs to be updated before executing the job.
CLIENT_JOB_PREPARING = 1
Calculates hashes for the elements that will be updated and to some extent serialize data that will be sent inline.
CLIENT_JOB_QUERYING_CACHE_STATUS = 2
Determining how much data needs to be uploaded before executing this job. The elements that need to be updated is now known, but there are still pending cache status requests. The job might not enter this state if no cache status requests were needed, or if all requests were already answered while in state CLIENT_JOB_PREPARING.
CLIENT_JOB_UPLOADING = 3
Uploading data. There are no pending cache status requests left and it is known how much data needs to be uploaded before executing the job. The job does not enter this state if there were no cache misses or if all data was already uploaded in previous states.
CLIENT_JOB_PENDING = 4
Waiting for execution of the job to finish. All data needed by the job is now uploaded and the job is either executing on the server or waiting for all previous jobs to finish before it can start executing. To get progress feedback in this state it is possible for the server-side job to send partial results back to the client.
CLIENT_JOB_DONE = 5
The result has been received and deserialized by the client-side job and the job is done.
CLIENT_JOB_FORCE_32_BIT = 0xffffffffU
enum mi::bridge::Client_session_state

The different states a client session can be in.

See also:

mi::bridge::IClient_session::get_state()

Enumerator:

CLIENT_SESSION_CONNECTING
The session is trying to establish a connection to the remote Bridge application for the first time.
CLIENT_SESSION_CONNECTED
The session has successfully established a connection to the Bridge server and is ready for use.
CLIENT_SESSION_PENDING
The session was disconnected unexpectedly. The session cannot be used in this state, but will automatically attempt to reconnect and resume the session. Session resume is only possible if the corresponding server-side session is still available when reconnecting, if not the session will be closed.Note that session resume is currently not supported so disconnected sessions will always be closed.
CLIENT_SESSION_CLOSED
The session has been closed in an orderly fashion, or the session has been pending but the session could not be resumed. Once a session has been closed it can not be used anymore. To attempt a reconnection a new session must be opened.