MigratoryData Client API for iOS
Developer's Guide and Reference Manual
MigratoryDataClient Class Reference

This class implements all the necessary operations for connecting to a cluster of one or more MigratoryData servers, subscribing to subjects, getting real-time messages for the subscribed subjects, and publishing real-time messages. More...

Inheritance diagram for MigratoryDataClient:

Instance Methods

(id) - init
 Create a MigratoryDataClient object.
 
(void) - setLogType:
 Configure the logging level. More...
 
(void) - setListener:
 Attach a MigratoryDataListener for handling real-time messages and status notifications. More...
 
(void) - setServers:
 Specify a cluster of one or more MigratoryData servers to which the client will connect to. More...
 
(void) - subscribe:
 Subscribe to one or more subjects. More...
 
(void) - subscribeWithConflation:conflationTimeMillis:
 Subscribe to one or more subjects with conflation. More...
 
(void) - unsubscribe:
 Unsubscribe from one or more subjects. More...
 
(void) - setEncryption:
 Configure whether to use SSL/TLS encryption when connecting to a MigratoryData server. More...
 
(void) - setEntitlementToken:
 Assign an authorization token to the client. More...
 
(NSArray *) - getSubjects
 Return the list of subscribed subjects. More...
 
(void) - setServersDownBeforeNotify:
 Define the number of consecutive failed attempts to connect to one or more MigratoryData servers before triggering a status notification NOTIFY_SERVER_DOWN. More...
 
(void) - notifyAfterReconnectRetries:
 Define the number of consecutive failed attempts to connect to one or more MigratoryData servers before triggering a status notification NOTIFY_SERVER_DOWN. More...
 
(void) - publish:
 Publish a message. More...
 
(void) - pause
 Pause the API operation. More...
 
(void) - resume
 Resume the API operation. More...
 
(void) - dispose
 Disconnect from the connected MigratoryData server and dispose the resources used by the connection. More...
 
(void) - setQuickReconnectMaxRetries:
 Define the maximum number of retries for the Quick Reconnect phase. More...
 
(void) - setQuickReconnectInitialDelay:
 Define the number of seconds to wait before attempting to reconnect to the cluster after a connection failure is detected. More...
 
(void) - setReconnectPolicy:
 Define the reconnect policy to be used after the Quick Reconnect phase. More...
 
(void) - setReconnectTimeInterval:
 Define the time interval used for the reconnect schedule after the Quick Reconnect phase. More...
 
(void) - setReconnectMaxDelay:
 Define the maximum reconnect delay for the TRUNCATED_EXPONENTIAL_BACKOFF policy. More...
 
(void) - setExternalToken:
 Assign an external token to a client. More...
 
(void) - setNumberOfHistoricalMessages:
 

Detailed Description

This class implements all the necessary operations for connecting to a cluster of one or more MigratoryData servers, subscribing to subjects, getting real-time messages for the subscribed subjects, and publishing real-time messages.

Method Documentation

◆ setLogType:()

- (void) setLogType: (LogType)  logLevel

Configure the logging level.

It is advisable to configure this first if you want to log as much as possible. The default log level is LogType.LOG_INFO.

Parameters
logLevelThe logging verbosity (LogType.LOG_ERROR, LogType.LOG_INFO, LogType.LOG_DEBUG or LogType.LOG_TRACE ); by default LogType.LOG_INFO is configured.

◆ setListener:()

- (void) setListener: (NSObject< MigratoryDataListener > *)  listener

Attach a MigratoryDataListener for handling real-time messages and status notifications.

Parameters
listenerAn instance of a class which implements the MigratoryDataListener interface

◆ setServers:()

- (void) setServers: (NSArray *)  servers

Specify a cluster of one or more MigratoryData servers to which the client will connect to.

If you specify two or more MigratoryData servers, then all these MigratoryData servers should provide the same level of data redundancy, by making available for subscription the same set of subjects. This is required for achieving (weighted) load balancing, failover, and guaranteed message delivery of the system. In this way, the MigratoryData servers of the servers list form a cluster.

For example, to connect to a cluster formed of two MigratoryData servers installed at the addresses p1.example.com and p2.example.com, and configured to accept clients on the standard HTTP port 80, the following code can be used:

NSArray *servers = [NSArray arrayWithObjects:"p1.example.com:80", @"p2.example.com:80"];
[client setServers:servers];

To achieve load-balancing, the API connects the client to a MigratoryData server chosen randomly from the servers list. In this way, the load is balanced among all the members of the cluster.

Moreover, the API supports weighted load-balancing. This feature is especially useful if the MigratoryData servers in the cluster are installed on machines with different capacities. You can assign to each member of the cluster a weight ranging from 0 to 100. This weight assignment is a hint provided to the API to select with a higher probability a MigratoryData server with a higher weight either initially when the client connects to the cluster or later during a failover reconnection.

Supposing the address p1.example.com corresponds to a machine that is twice more powerful than the machine having the address p2.example.com, then you can assign to p1.example.com a weight 100 and to p2.example.com a weight 50 by prefixing each address with the assigned weight as follows:

NSArray *servers = [NSArray arrayWithObjects:"100 p1.example.com", @"50 p2.example.com"];
[client setServers:servers];

The API assigns a default weight 100 to the addresses not prefixed with a specific weight.

To achieve failover, if the connection between the client and a MigratoryData server is broken, then the API will automatically detect the failure and will select another MigratoryData server from the servers list. If the client fails to connect to the new selected server, a status notification NOTIFY_SERVER_DOWN will be triggered (unless you modify the number of failed attempts with MigratoryDataClient::setServersDownBeforeNotify:), and a new MigratoryData server in the cluster will be selected again and again until the client will be able to connect to one of the MigratoryData servers in the cluster. When successfully connected, the API will trigger a status notification NOTIFY_SERVER_UP.

Furthermore, if guaranteed message delivery is enabled, then the potential messages published for a subscribed subject during the failover period, will be automatically retrieved from the cache of the MigratoryData server to which the client reconnects to and a status notification NOTIFY_DATA_SYNC will be triggered for that subject.

If, for example, the failover period is abnormally long, and the client is not able to retrieve, after a failover reconnection, the messages published during the failover period for one of its subscribed subjects, then the API will retrieve only the most recent message available for that subject and will trigger a NOTIFY_DATA_RESYNC status notification for that subject, the client behaving as a new client which connects to the cluster at the moment of the failover reconnection.

For a complete discussion related to load balancing, failover, and guaranteed message delivery features see the MigratoryData Architecture Guide (PDF, HTML).

Parameters
serversAn array of strings where each string represents the network address (IP address or DNS domain name and its corresponding port) of a MigratoryData server, optionally prefixed by a weight ranging from 0 to 100. If the weight prefix is not provided to an address, then the API will automatically assign to that address a default weight 100.

◆ subscribe:()

- (void) subscribe: (NSArray *)  subjects

Subscribe to one or more subjects.

Subscribe for real-time messages having as subjects the strings provided in the subjects parameter.

As an example, supposing messages are market data updates having as subjects stock names. Then, to subscribe for the messages having as subjects /stocks/NYSE/IBM and /stocks/Nasdaq/MSFT the following code will be used:

NSMutableArray *subjects = [NSMutableArray new];
[subjects addObject:"/stocks/NYSE/IBM"];
[subjects addObject:@"/stocks/Nasdaq/MSFT"];
[client subscribe:subjects];

The subjects are strings having a particular syntax. See the Chapter "Concepts" in the MigratoryData Architecture Guide (PDF, HTML) to learn about the syntax of the subjects.

Parameters
subjectsAn array of strings representing subjects.

◆ subscribeWithConflation:conflationTimeMillis:()

- (void) subscribeWithConflation: (NSArray *)  subjects
conflationTimeMillis: (int)  conflationMillis 

Subscribe to one or more subjects with conflation.

Subscribe for real-time messages having as subjects the strings provided in the subjects parameter.

If the optional parameter conflationMillis is used, then for each subject in the subjects list given in argument, its messages will be aggregated in the MigratoryData server and published every conflationMillis milliseconds as aggregated data (containing only the latest value for that subject and its latest field values). The value of conflationMillis should be a multiple of 100 milliseconds, otherwise the MigratoryData server will round it to the nearest value multiple of 100 milliseconds (e.g. 76 will be rounded to 0, 130 will be rounded to 100, 789 will be rounded to 700, ...). If the value of conflationMillis is 0 (or is rounded to 0), then no conflation will apply, and data publication will be message-by-message with no message aggregation.

As an example, supposing the messages are market data updates having as subjects stock names. Then, to subscribe for the messages having as subjects /stocks/NYSE/IBM and /stocks/Nasdaq/MSFT using 1-second conflation the following code will be used:

NSMutableArray *subjects = [NSMutableArray new];
[subjects addObject:"/stocks/NYSE/IBM"];
[subjects addObject:@"/stocks/Nasdaq/MSFT"];
[client subscribeWithConflation:subjects conflationTimeMillis:1000];

The subjects are strings having a particular particular syntax. See the Chapter "Concepts" in the MigratoryData Architecture Guide (PDF, HTML) to learn about the syntax of the subjects.

Parameters
subjectsAn array of strings representing subjects.
conflationMillisAn optional argument defining the number of milliseconds used to aggregate ("conflate") the messages for each subject in the subjects list; default value is 0 meaning that no conflation will apply, and data publication will be message-by-message with no message aggregation.

◆ unsubscribe:()

- (void) unsubscribe: (NSArray *)  subjects

Unsubscribe from one or more subjects.

Unsubscribe from the subscribed subjects provided in the subjects parameter.

Parameters
subjectsAn array of strings representing subjects.

◆ setEncryption:()

- (void) setEncryption: (BOOL)  encryption

Configure whether to use SSL/TLS encryption when connecting to a MigratoryData server.

When using encryption you have to connect to the ports of the MigratoryData servers that are configured to listen for encrypted connections. See the parameter ListenEncrypted in the MigratoryData Configuration Guide (PDF, HTML).

Parameters
encryptionDetermine whether the client connects to the MigratoryData server using an encrypted SSL/TLS connection

◆ setEntitlementToken:()

- (void) setEntitlementToken: (NSString *)  token

Assign an authorization token to the client.

To define which users of your application have access to which subjects, you will first have to set the parameter Entitlement on true in the configuration file of the MigratoryData server ‚see the parameter Entitlement in the MigratoryData Configuration Guide (PDF, HTML).

Then, you will have to use the entitlement-related part of the MigratoryData Extension API to allow or deny certain users to subscribe / publish to certain subjects.

Parameters
tokenA string representing an authorization token.

◆ getSubjects()

- (NSArray *) getSubjects

Return the list of subscribed subjects.

Returns
The list of strings representing the subscribed subjects.

◆ setServersDownBeforeNotify:()

- (void) setServersDownBeforeNotify: ("Use notifyAfterReconnectRetries instead")  DEPRECATED_MSG_ATTRIBUTE

Define the number of consecutive failed attempts to connect to one or more MigratoryData servers before triggering a status notification NOTIFY_SERVER_DOWN.

Deprecated:
Use MigratoryDataClient::notifyAfterReconnectRetries: instead.
Parameters
nThe number of consecutive failed attempts to connect to one or more MigratoryData servers before triggering a status notification NOTIFY_SERVER_DOWN; default value is 1.

◆ notifyAfterReconnectRetries:()

- (void) notifyAfterReconnectRetries: (int)  n

Define the number of consecutive failed attempts to connect to one or more MigratoryData servers before triggering a status notification NOTIFY_SERVER_DOWN.

Parameters
nThe number of consecutive failed attempts to connect to one or more MigratoryData servers before triggering a status notification NOTIFY_SERVER_DOWN; default value is 1.

◆ publish:()

- (void) publish: (MigratoryDataMessage *)  message

Publish a message.

If the message includes a closure data, then a status notification will be provided via MigratoryDataListener::onStatus:info: to inform whether the message publication has been successful or failed.

Parameters
messageA MigratoryDataMessage message

◆ pause()

- (void) pause

Pause the API operation.

If the application built with this API library enters into background, then it is recommended to use this API call. It will disconnect the user from the MigratoryData sever but will preserve the user's context (including the cluster definition and subscribed subjects) in order to reconnect to the cluster later when the API method MigratoryDataClient::resume is called.

Moreover, if the cluster is configured with guaranteed message delivery, then when the user will reconnect to the cluster using MigratoryDataClient::resume, it will get all messages published since the MigratoryDataClient::pause method was called, provided however that the duration between the time when MigratoryDataClient::pause method was called and the MigratoryDataClient::resume method was called is less than the value defined by the parameter CacheExpireTime of the MigratoryData server (see details about this parameter in MigratoryData Configuration Guide (PDF, HTML).

◆ resume()

- (void) resume

Resume the API operation.

If the application was paused with the MigratoryDataClient::pause method, then this API call will attempt to reconnect the user to the cluster. Also, if guaranteed message delivery is enabled, this method also retrieves all messages published since the MigratoryDataClient::pause has been called provided that the duration between the time when MigratoryDataClient::pause method was called and the MigratoryDataClient::resume method was called is smaller than the value defined by the parameter CacheExpireTime.

This method will be typically used when the application switches to foreground.

◆ dispose()

- (void) dispose

Disconnect from the connected MigratoryData server and dispose the resources used by the connection.

This method should be called when the connection is no longer necessary.

◆ setQuickReconnectMaxRetries:()

- (void) setQuickReconnectMaxRetries: (int)  retries

Define the maximum number of retries for the Quick Reconnect phase.

Parameters
retriesThe maximum number of quick reconnect retries; default value is 3.

◆ setQuickReconnectInitialDelay:()

- (void) setQuickReconnectInitialDelay: (int)  seconds

Define the number of seconds to wait before attempting to reconnect to the cluster after a connection failure is detected.

Connection Failure Detection

Connection failure is detected immediately for almost all users running modern browsers. For a few users running modern browsers (and being subject to temporary, atypical network conditions) as well as for all users running older browsers without WebSocket support, connection failure is detected after 30-40 seconds.

Reconnection Phases and Policies

When a connection failure is detected, the API will attempt to reconnect to the servers of the MigratoryData cluster as follows: First, it will attempt to reconnect (up to a number of times as defined by MigratoryDataClient::setQuickReconnectMaxRetries()) using small delays between retries (the Quick Reconnection phase). If the connection cannot be established after the Quick Reconnection phase, then the API will attempt to reconnect less frequently according to the policy defined by MigratoryDataClient::setReconnectPolicy().

The delays between retries are computed acoording to the following algoritm where the values of the variables involved are defined by the API methods having substantially the same names:

   Quick Reconnect Phase (retries <= quickReconnectMaxRetries)
   -----------------------------------------------------------
      (retries starts with 1 and increment by 1 at each quick reconnect)
      reconnectDelay = quickReconnectInitialDelay * retries - random(0, quickReconnectInitialDelay)
   After Quick Reconnect Phase (retries > quickReconnectMaxRetries)
   ----------------------------------------------------------------
      (reset retries to start with 1 and increment by 1 at each reconnect)
      If reconnectPolicy is CONSTANT_WINDOW_BACKOFF, then
         reconnectDelay = reconnectTimeInterval
      else if reconnectPolicy is TRUNCATED_EXPONENTIAL_BACKOFF, then
         reconnectDelay = min(reconnectTimeInterval * (2 ^ retries) - random(0, reconnectTimeInterval * retries), reconnectMaxDelay)

For a few users running modern browsers (and being subject to temporary, atypical network conditions) as well as for all users running older browsers without WebSocket support, if reconnectDelay computed with the algorithm above is less than 10 seconds, then it is rounded to 10 seconds.

Parameters
secondsThe number of seconds to wait before attempting to reconnect to the cluster; default value is 5 seconds.

◆ setReconnectPolicy:()

- (void) setReconnectPolicy: (NSString *)  policy

Define the reconnect policy to be used after the Quick Reconnect phase.

See MigratoryDataClient::setQuickReconnectInitialDelay() to learn about the Quick Reconnect phase and the reconnect schedule for the policy defined by this method.

Parameters
policyThe reconnect policy to be used after the Quick Reconnect phase. The possible values are CONSTANT_WINDOW_BACKOFF and TRUNCATED_EXPONENTIAL_BACKOFF; the default value is TRUNCATED_EXPONENTIAL_BACKOFF.

◆ setReconnectTimeInterval:()

- (void) setReconnectTimeInterval: (int)  seconds

Define the time interval used for the reconnect schedule after the Quick Reconnect phase.

See MigratoryDataClient::setQuickReconnectInitialDelay() to learn about the Quick Reconnect phase and how the value defined by this API method is used.

Parameters
secondsA time interval expressed in seconds; default is 20 seconds.

◆ setReconnectMaxDelay:()

- (void) setReconnectMaxDelay: (int)  seconds

Define the maximum reconnect delay for the TRUNCATED_EXPONENTIAL_BACKOFF policy.

See MigratoryDataClient::setQuickReconnectInitialDelay() to learn how the value defined by this API method is used.

Parameters
secondsThe maximum reconnect delay when the policy TRUNCATED_EXPONENTIAL_BACKOFF is used; default value is 360 seconds.

◆ setExternalToken:()

- (void) setExternalToken: (NSString *)  externalToken

Assign an external token to a client.

An external token which is provided by a client using this method is typically used by a MigratoryData plugin to enable that client to communicate with an external service.

For example the MigratoryData plugin for Firebase needs an FCM token in order to be able to push notifications via the Firebase service to a mobile client. The mobile client can provide the FCM token to the plugin using this method.

Parameters
externalTokenA string representing an external token