Type of the header containing initial data.
Type of additional features provided for the remote server. If no plan to provide anything, declare null.
Initializer Constructor.
Initial data sending to the remote server after connection. Hope to use it as an activation tool.
Additional feature provided for the remote server. If don't plan to provide anything to the remote server, assign null.
Current state of the MutexConnector
Get header.
Get state.
Get current state of connection state with the mutex-server. List of values are such like
below:
NONE: The MutexConnector instance is newly created, but did nothing yet.CONNECTING: The MutexConnector.connect method is on running.OPEN: The connection is online.CLOSING: The MutexConnector.close method is on running.CLOSED: The connection is offline.Get connection url.
Close connection.
Close connection from the remote mutex-server.
When connection with the mutex-server has been closed, all of the locks you had acquired
and tried would be automatically unlocked and cancelled by the server. Therefore, if you've
tried to get locks through the remote critical section components by calling their methods,
those methods would throw RuntimeError exceptions.
Also, the disconnection destories all RFCs
between the remote server. Therefore, if you or server has an additional Provider and
there're uncompleted method calls to the Provideer through the Driver<Controller>,
RuntimeError exceptions would be thrown.
Connect to a remote mutex-server.
Try connection to the remote mutex-server with its address and waiting for the server
to accept the trial. If the mutex-server accepts your connection, the function would be
returned. Otherwise, the server rejects your connection, an exception would be thrown.
After the connection and your business (using remote critical sections) has been completed, please don't forget closing the connection in time to prevent waste of the server resource.
URL address to connect.
Get remote barrier.
Get remote barrier from the mutex-server.
If the mutex-server doesn't have the key named barrier, the server will create a new
barrier instance with your count*. Otherwise, the server already has the *key named
barrier, server will return it directly.
Therefore, if the server already has the key named barrier, its downward counter can be different with your count.
An identifier name to be created or search for.
Downward counter of the target barrier, if newly created.
A RemoteBarrier object.
Get remote condition variable.
Get remote condition variable from the mutex-server.
If the mutex-server doesn't have the key named condition variable, the server will
create a new condition variable instance. Otherwise, the server already has the key named
condition variable, server will return it directly.
An identifier name to be created or search for.
A RemoteConditionVariable object.
Get Driver for RFC.
If your target MutexServer provides additional features, you can utilize those
features through returned Driver object by this method. To use this method, you should
define the Controller template argument, a type of interface who is defining additional
features provided from the remote server.
The returned object Driver makes to call remote functions, defined in the Controller
and provided by Provider in the remote server, possible. In other words, callling a
function in the Driver<Controller>, it means to call a matched function in the remote
server's Provider object.
Controller: Definition onlyDriver: Remote Function CallAn interface for provided features (functions & objects) from the remote system (Provider).
Whether to convert type of function parameters to be compatible with their pritimive.
A Driver for the RFC.
Get remote latch.
Get remote latch from the mutex-server.
If the mutex-server doesn't have the key named latch, the server will create a new
latch instance with your count*. Otherwise, the server already has the *key named latch,
server will return it directly.
Therefore, if the server already has the key named latch, its downward counter can be different with your count.
An identifier name to be created or search for.
Downward counter of the target latch, if newly created.
A RemoteLatch object.
Get remote mutex.
Get remote mutex from the mutex-server.
If the mutex-server doesn't have the key named mutex, the server will create a new
mutex instance. Otherwise, the server already has the key named mutex, server will return
it directly.
An identifier name to be created or search for.
A RemoteMutex object.
Get remote semaphore.
Get remote semaphore from the mutex-server.
If the mutex-server doesn't have the key named semaphore, the server will create a new
semaphore instance with your count*. Otherwise, the server already has the *key named
semaphore, server will return it directly.
Therefore, if the server already has the key named semaphore, its RemoteSemaphore.max can be different with your count.
An identifier name to be created or search for.
Downward counter of the target semaphore, if newly created.
A RemoteSemaphore object.
Join connection.
Wait until connection with the server to be closed.
Join connection until timeout.
Wait until connection with the server to be clsoed until timeout.
The maximum miliseconds for waiting.
Whether succeeded to waiting in the given time.
Join connection until time expiration.
Wait until connection with the server to be closed until time expiration.
The maximum time point to wait.
Whether succeeded to waiting in the given time.
Generated using TypeDoc
Mutex server connector for client.
The MutexConnector is a communicator class who can connect to a remote
mutex-serverand interact with it through websocket and RFC protocol.You can connect to the websocket
mutex-serverusing connect method. After the connection, get network level remote critical section components using one of below methods. After utilizing those components, please do not forget to realising the component by calling {@link IRemoteComponent.destructor} or closing connection with themutex-serverby calling the close method to prevent waste of resources of themutex-server.Also, when declaring this MutexConnector type, you've to define two template arguments, Header and Provider*. The *Header type repersents an initial data sending to the remote
mutex-serverafter connection. I hope you not to omit it and utilize it as an activation tool to enhance security.The second template argument Provider represents the custom features provided for the remote
mutex-server. If you don't have any plan to provide any feature to themutex-server, just declare it asnull.Jeongho Nam - https://github.com/samchon