The Bridge client is integrated in the application that wishes to use the resources of the remote cluster. More...
Classes | |
class | mi::bridge::IClient_job_progress |
Provides detailed information about the progress of a Bridge job. More... | |
class | mi::bridge::IElement_set |
Used to specify a set of elements by name. More... | |
class | mi::bridge::IClient_job |
Represents the client-side part of a job that can be executed by the Bridge server. More... | |
class | mi::bridge::Client_job<i_id1, i_id2, i_id3, i_id4, i_id5, i_id6, i_id7, i_id8, i_id9, i_id10, i_id11, I> |
This mixin class provides a default implementation for some of the methods needed by mi::bridge::IClient_job. More... | |
class | mi::bridge::Update_job |
Base class for Bridge jobs that only update elements without executing anything. More... | |
class | mi::bridge::IClient_session_state_callback |
Abstract interface for callbacks for session state changes. More... | |
class | mi::bridge::IClient_measure_bandwidth_callback |
Abstract interface for bandwidth measurement events. More... | |
class | mi::bridge::IClient_session |
Represents the client side of a Bridge session. More... | |
class | mi::bridge::IBridge_client |
API component that serves as entry point for the client-side Bridge API. More... | |
class | mi::bridge::IClient_video_context |
Client-side video context that receives and decodes video frames from the corresponding server-side video context. More... | |
class | mi::bridge::IVideo_frame |
Represents the data for a single video frame. More... | |
class | mi::bridge::IVideo_sink |
Abstract interface to receive video frames produced by the corresponding server-side video context. More... | |
class | mi::bridge::IIray_bridge_snapshot_callback |
Abstract interface for snapshot events. More... | |
class | mi::bridge::IIray_bridge_snapshot_context |
Context for creating Iray Bridge snapshots. More... | |
class | mi::bridge::IIray_bridge_session |
Represents a session (connection) to an Iray Bridge Server. More... | |
class | mi::bridge::IIray_bridge_client |
API component that serves as entry point for the client-side Iray Bridge API. More... | |
Enumerations | |
enum | mi::bridge::Client_job_state { mi::bridge::CLIENT_JOB_DETECTING_CHANGES = 0 , mi::bridge::CLIENT_JOB_PREPARING = 1 , mi::bridge::CLIENT_JOB_QUERYING_CACHE_STATUS = 2 , mi::bridge::CLIENT_JOB_UPLOADING = 3 , mi::bridge::CLIENT_JOB_PENDING = 4 , mi::bridge::CLIENT_JOB_DONE = 5 , CLIENT_JOB_FORCE_32_BIT = 0xffffffffU } |
Job states of Bridge jobs. More... | |
enum | mi::bridge::Client_session_state { mi::bridge::CLIENT_SESSION_CONNECTING , mi::bridge::CLIENT_SESSION_CONNECTED , mi::bridge::CLIENT_SESSION_PENDING , mi::bridge::CLIENT_SESSION_CLOSED } |
The different states a client session can be in. More... | |
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.
The API consists of two layers: a low-level API, called Bridge API, and a high-level API, called Iray Bridge API. The low-level Bridge API is generic and independent of domain-specific tasks like rendering. It exposes the full flexibility of the Bridge. The high-level Iray Bridge API is specific to rendering. It encapsulates the details of the Bridge API and exposes them in a simpler way sufficient for rendering. Using the high-level API is strongly recommended unless there are specific needs which require the use of the low-level API. See the API component mi::bridge::IBridge_client for the Bridge API, and mi::bridge::IIray_bridge_client for the Iray Bridge API.
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.
The different states a client session can be in.