ThingWorx Edge C SDK > How to Set Up an Application > Connecting to the ThingWorx Platform and Initiating Defined Tasks
Connecting to the ThingWorx Platform and Initiating Defined Tasks
The recommended order is to connect to the ThingWorx Platform first and then initiate tasks, especially if your tasks are pushing data to the platform. If you start the tasks earlier, they may attempt to send property updates or invoke services on the platform before the connection is established. While reversing the order does not cause any lasting problems, it tends to keep the system very busy with retries before the connection is established.
The connection to the platform is attempted and retried with the parameters specified to the twApi_Connect() function. By default, the API automatically reconnects using the same parameters if the connection is subsequently lost. This behavior can be overridden when the API is initialized by setting the autoreconnect parameter to FALSE.
The default setting for DEFAULT_SOCKET_READ_TIMEOUT in twDefaultSettings.h is 0. This value is recommended for best performance when transferring large files. Refer to Best Practices for Transferring Large Files.
The API also supports callback notifications when a connection is successfully made and when a connection is lost. The signature for “event callback” functions can be found in the file, src/messaging/twMessaging.h, and the task registration functions are found in the file, twApi.h.
/* Connect to platform */
if (!twApi_Connect(CONNECT_TIMEOUT, twcfg.connect_retries)) {
/* Register our "Data collection Task" with the tasker */
twApi_CreateTask(DATA_COLLECTION_RATE_MSEC, dataCollectionTask);
Performance Tip - Socket Read Timeout
If you are experiencing slow performance during high traffic C SDK operations, it could be beneficial to decrease the twcfg.socket_read_timeout. With this change, more blocked threads can access the receiving socket to look for the messages that they are expecting. While smaller values lead to increased performance, it is important to keep in mind that the smaller the value of twcfg.socket_read_timeout, the higher the CPU usage. This increased CPU usage should be monitored, especially on power-constrained devices, for example battery operated devices.
Was this helpful?