next up previous contents
Next: 5. Examples Up: Status Server Client C Previous: 3. API Primer   Contents

Subsections

4. Detailed API

4.1 ssLogon() - Establish a connection to the Status Server

Before any other API calls are made to view, create, update, remove, or monitor information within the Status Server, this routine must be called to establish a connection. Once a connection is established to the Status Server, from the client perspective it remains persistent until the client chooses to disconnect from the Status Server.

If the Status Server itself is halted or the network connection between the client and Status Server is broken, the client API will enter into a blocking wait and retry process. As a result, it is not necessary for the client to check whether a connection failure occured following a successful connection. This approach is very similar to an NFS client-server interaction.

Call syntax


    PASSFAIL ssLogon(const char *name)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.2 ssLogoff() - Disconnect from the Status Server

The connection between the client and Status Server will remain persistent until the client calls the ssLogoff() function to disconnect.


    void ssLogoff(void)

4.3 ssGetError() - Get the enumerated error value

Whenever an error occured on a Status Server API call, the enumerated value for the error code can be retrieved using this function call. This is very similar to what can be done at a system level with the external integer errno.

Call syntax


    ss_errno_t ssGetError(void)

Return value

This function will return the value of the enumerated type ss_errno_t. The possible enumerated type possibilities are:

4.4 ssGetStrError() - Get the enumerated error value

This routine will return back a pointer to a string containing descriptive text of the last error which occured on a Status Server API call. Please see the previous section for more details regarding the possible errors. This is very similar to what can be done at a system level with the call strerror(errno).

Call syntax


    const char *ssGetStrError(void)

Return value

Descriptive string containing error details.

4.5 ssDisconnectCallback() - Register a callback function in case of a disconnect

This routine allows a client the ability to register a callback function which will be called whenever the client is disconnected from the Status Server. If the user wishes to remove a previously defined callback routine, this routine can be called with the callback function set to NULL.

It is important to note that this callback function will not be called if a client invokes the ssLogoff() routine.

Call syntax


    void ssDisconnectCallback(ss_callback_fn callback)

Input parameters

4.6 ssReconnectCallback() - Register a callback function in case of a re-connect

This routine allows a client the ability to register a callback function which will be called whenever the client is re-connected to the Status Server. If the user wishes to remove a previously defined callback routine, this routine can be called with the callback function set to NULL.

It is important to note that this callback function will not be called if a client invokes the ssLogoff() routine.

Call syntax


    void ssReconnectCallback(ss_callback_fn callback)

Input parameters

4.7 Create an object or register the intent to modify or remove an object

Prior to either updating or removing an object within the Status Server, the client must perform a ``touch'' on the object. The touch enables a client to specify the intent to update or modify a value in the Status Server. If the data object does not exist before this call is made, it will be created with a state indicating that the object value is undefined.

This routine must also be used if a client wishes to change either the comment associated with an object or the lifetime.

Once a touch is placed on an object, it cannot be completely removed from the Status Server until the use counts for the object are zero. This means that no clients currently have an outstanding touch, monitor, or directory listing on the object. As a result, once a client performs a touch on an object, it is guaranteed to be available for updating.

There are four different API calls which can be used to perform a touch on an object. Each of the different API calls is described in the following sections.

4.7.1 ssTouchObject() - Touch object without specifying a lifetime

This function call can be used if you don't wish to modify modify the current lifetime associated with an object. If the object does not yet exist when this call is made, it will be created with an unlimited lifetime.

Call syntax


    PASSFAIL ssTouchObject(const char *name,
                           const char *comment)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.7.2 ssTouchObjectWithLifetime() - Touch object with a specified lifetime

This routine performs the same functionality as the ssTouchObject() call with the additional benefit of setting the lifetime of the object.

Call syntax


    PASSFAIL ssTouchObjectWithLifetime(const char *name,
                                       const char *comment,
                                       time_t lifetime)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.7.3 ssTouchObjectWithAutoExpire() - Touch object with lifetime based on duration of client connection

This function performs a touch on an object with the lifetime based on the duration of the client socket connection. For example, if you use this function and update an object in the Status Server, it will be considered valid until your client connection to the Status Server is broken at which point the object will change state to EXPIRED.

Call syntax


    PASSFAIL ssTouchObjectWithAutoExpire(const char *name,
                                         const char *comment)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.7.4 ssTouchObjectExpire() - Touch object and set value to EXPIRED

This function will initiate a touch on an object in the Status Server and immediately change the value to be EXPIRED.

Call syntax


    PASSFAIL ssTouchObjectExpire(const char *name,
                                 const char *comment)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.8 ssTouchdir() - Create a new directory or register the intent to remove a directory

The call serves two main purposes. First, it allow for a directory to be created if it doesn't already exists. Secondly, it can allow a client to register the intent to remove a directory from the Status Server. If the directory does not exist before this call is made, it will be created with an update count value of ``1''.

This routine must also be used if a client wishes to change the comment associated with a directory.

Once a touch is placed on the directory, it cannot be completely removed from the Status Server until the use counts for the directory are zero. This means that no clients currently have an outstanding touch, monitor, or directory listing on the directory. As a result, once a client performs a touch on a directory, it is guaranteed to remain persistent until an ``untouch'' is performed.

Call syntax


    PASSFAIL ssTouchDir(const char *path,
                        const char *comment)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.9 ssUntouch() - Remove the touch from a Status Server data object or directory

Once a touch is placed on an object or directory, it cannot be completely removed from the Status Server until the use counts for the object or directory are zero. This means that no clients currently have an outstanding touch, monitor, or directory listing on the object or directory. As a result, if a client creates an object or directory by performing a touch or touchdir and another client is responsible for removing the object or directory, the first client must ``untouch'' the object or directory before it can be completely removed by the second client.

Call syntax


    PASSFAIL ssUntouch(const char *name)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.10 Update an object in the Status Server

Once a successful touch has been performed on an object, it is possible for the client to initiate an update request. The update request causes the value associated with the object to be modified. The client can update a Status Server object with either string, integer, double, or boolean data.

4.10.1 ssPutString() - Update with a string value

Call syntax


    PASSFAIL ssPutString(const char *name,
                         const char *value)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.10.2 ssPutInt() - Update with an integer value

Call syntax


    PASSFAIL ssPutInt(const char *name,
                      long value)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.10.3 ssPutDouble() - Update with a double-precision floating point value

Call syntax


    PASSFAIL ssPutDouble(const char *name,
                         double value)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.10.4 ssPutBoolean() - Update with a boolean value

Call syntax


    PASSFAIL ssPutBoolean(const char *name,
                          BOOLEAN value)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.10.5 ssPutPrintf() - Update with a printf style argument

Call syntax


    PASSFAIL ssPutPrintf(const char *name,
                         const char *fmt, ...)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.11 Retrieve the value of an object from the Status Server

Since the Status Server is an open repository without permissions, any client has the ability to retrieve an object from the Status Server. Within the Status Server itself, values are stored as strings. The API provides the ability to extract information from the Status Server as either a string, integer, double or boolean value.

4.11.1 ssGetString() - Retrieve the value as a string

The information within the Status Server is stored in a modified URL encoded format. This routine will unencode the string and store it within a string specified by the user. The client will receive all the Status Server data up to the maximum length specified by the client. If length of the Status Server string is larger than the amount of room specified by the client, the string will be truncated.

Call syntax


    PASSFAIL ssGetString(const char *name,
                         char *value,
                         size_t max_len)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.11.2 ssGetInt() - Retrieve the value as an integer

Call syntax


    PASSFAIL ssGetInt(const char *name,
                      long *value)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.11.3 ssGetDouble() - Retrieve the value as a double-precision floating point number

Call syntax


    PASSFAIL ssGetDouble(const char *name,
                         double *value)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.11.4 ssGetBoolean() - Retrieve the value as a boolean

Call syntax


    PASSFAIL ssGetBoolean(const char *name,
                          BOOLEAN *value)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.12 ssRemove() - Remove an object from the Status Server

Once a successful touch has been performed on an object, it is possible for the client to initiate a removal request of the object within the Status Server.

The data object cannot be completely removed from the Status Server until the use counts for the object are zero. This means that no clients currently have an outstanding touch, monitor, or directory listing on the object. If the use counts are greater than zero, the object will be put in a state of ``NONEXISTENT'' and will be removed completely whenever the use counts do go to zero. In the meantime, any request to ``get'' or ``stat'' the object will return an indication that the object does not exist as if it was completely removed from the Status Server.

Call syntax


    PASSFAIL ssRemove(const char *name)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.13 ssStat() - Check for the existence and status of an object

This function will check whether a specific data object exists in the Status Server and if so, return its status.

Call syntax


    PASSFAIL ssStat(const char *name,
                    ss_stat_t *status)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.14 ssGetAttributes() - Retrieve the attributes of a Status Server object or directory

This routine will return all the important attributes associated with a data object or directory. The information return is the same information as what is returned as part of a directory listing.

Call syntax


    const ss_dirent_t *ssGetAttributes(const char *name)

Input parameters

Return value

This function will either return a populated ss_dirent_t data structure, or NULL. If the function should return NULL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.15 Place a monitor on an object

The client has the option of placing a monitor on any object with an optional deadband value. If a deadband are not desired, it can be set to 0. This indicates the client would like to monitor each change to an object value.

Once a monitor is placed on an object, the client must use the ssPoll() or ssWait() routine to retrieve updated monitor information.

Monitor changes to object can then be handled one of two ways. The client can specify a callback function to be called whenever the object changes, or the client can specify memory locations where the object value and value status will be updated. The value status enables the client to know when the state of an object changes, since an object can be valid, expired, undefined, or deleted. When a callback function is used, the updated value is always returned as a string.

4.15.1 ssMonitorCallback() - Place a monitor on an object and be informed of the change via a callback

Following an ssPoll() or ssWait() API call, if the value of a data object changes on the Status Server beyond the deadband threshold, the new value and status will be passed to a user callback function, along with the arbitrary 'userptr' provided by the user.

Call syntax


    PASSFAIL ssMonitorCallback(const char *name,
                               double deadband,
                               ssMonitorCallbackFunc userfunc,
                               void *userptr)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.15.2 ssMonitorString() - Place a monitor on an object and retrieve updates as a string

Following an ssPoll() or ssWait() API call, if the value of a data object changes on the Status Server, a new string value will be stored in the string buffer specified by the user. The string buffer specified by the client will be populated with the Status Server data up to the maximum length specified by the client. If length of the Status Server string is larger than the amount of room specified by the client, the string will be truncated.

Call syntax


    PASSFAIL ssMonitorString(const char *name,
                             size_t max_len,
                             char *value,
                             ss_stat_t *value_status)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.15.3 ssMonitorInt() - Place a monitor on an object and retrieve updates as an integer

Following an ssPoll() API call, if the value of a data object changes on the Status Server beyond the deadband threshold specified, a new integer value will be stored at the integer memory address specified by the user.

Call syntax


    PASSFAIL ssMonitorInt(const char *name,
                          long deadband,
                          long *value,
                          ss_stat_t *value_status)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.15.4 ssMonitorDouble() - Place a monitor on an object and retrieve updates as a double-precision floating point number

Following an ssPoll() API call, if the value of a data object changes on the Status Server beyond the deadband threshold specified, a new double-precision floating point number value will be stored at the memory address specified by the user.

Call syntax


    PASSFAIL ssMonitorDouble(const char *name,
                             double deadband,
                             double *value,
                             ss_stat_t *value_status)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.15.5 ssMonitorBoolean() - Place a monitor on an object and retrieve updates as a boolean

Following an ssPoll() API call, if the value of a data object changes on the Status Server, a new boolean value will be stored at the memory address specified by the user.

Call syntax


    PASSFAIL ssMonitorBoolean(const char *name,
                              BOOLEAN *value,
                              ss_stat_t *value_status)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.16 Place a monitor on a directory

The client has the option of placing a monitor on any directory. Within the Status Server, an update counter is maintained with each directory. This counter is incremented any time the value of a data object within that directory is modified. As a result, a client could place a monitor on a directory and perform a directory listing to get the new values of a directory following a change. One potential application where this could be useful is if a directory is used to store the values within a GUI drop-down list. If a new data object is added or removed, the client could place a monitor on the directory and update the possible options within the drop-down list dynamically.

It is possible to specify a deadband in order to limit the notifications of directory updates. In most cases, it will probably be desirable to be notified of all directory updates, in which case the deadband value must be set to 0.

Once a monitor is placed on a directory, the client must use the ssPoll() or ssWait() routine to retrieve updated monitor information.

Monitor changes to a directory can be handled one of two ways. The client can specify a callback function to be called whenever the contents of a directory change, or the client can specify memory locations where the directory count and value status will be updated. The value status enables the client to know when the state of a directory changes, since a directory can be either be valid or deleted. When a callback function is used, the updated value is always returned as a string

4.16.1 ssMonitorDirCallback() - Place a monitor on a directory and be informed of the change via a callback

Following an ssPoll() or ssWait() API call, if the contents of a directory change, the new value and status will be passed to a user callback function, along with the arbitrary 'userptr' provided by the user.

Call syntax


    PASSFAIL ssMonitorDirCallback(const char *path,
                                  ssMonitorCallbackFunc userfunc,
                                  void *userptr)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.16.2 ssMonitorDir() - Place a monitor on a directory

Following an ssPoll() or ssWait() API call, if the contents of a directory change, the client can specify a memory location to hold the new directory count and value status.

Call syntax


    PASSFAIL ssMonitorDir(const char *path,
                          long *value,
                          ss_stat_t *status)

Input parameters

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.17 ssUnmonitor() - Remove the monitor from a data object or directory

This routine will remove a monitor from a data object or directory currently monitored by the client.

Call syntax


    PASSFAIL ssUnmonitor(const char *name)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.18 ssPoll() - Check for and, if available, retrieve monitor updates

This routine will initiate a check whether any monitored information is available for retrieval by the C API and, if so, retrieve the monitored data from the Status Server and either call the client registered callback function or store the information in the memory locations whhich were previously defined during the setup of the monitor.

If a monitor request was made to monitor as an Integer, floating point, or boolean data types, a conversion will be performed from the string format received over the interface to the monitor requested data type. Any errors detected, either during the conversion process or from the data response sent by the Status Server, will be stored in the previously allocated memory location for return code information.

Call syntax


    PASSFAIL ssPoll(void)

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.19 ssWait() - Wait for a period and, if available, retrieve monitor updates

This routine is identical to the ssPoll() except it allow for a timeout to be supplied which indicates how long the timeout should be on a select() when waiting for activity to occur on a socket. If activity occurs on the socket, it will initiate a check whether any monitored information is available for retrieval by the C API and, if so, retrieve the monitored data from the Status Server and either call the client registered callback function or store the information in the memory locations whhich were previously defined during the setup of the monitor.

If a monitor request was made to monitor as an Integer, floating point, or boolean data types, a conversion will be performed from the string format received over the interface to the monitor requested data type. Any errors detected, either during the conversion process or from the data response sent by the Status Server, will be stored in the previously allocated memory location for return code information.

Call syntax


    PASSFAIL ssWait(int timeout_hundredths)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.20 ssSync() - Force client to synchronize itself with the server

This function will force mailbox retrieval message to be sent to the Status Server and will wait for a response from the Status Server. It is useful to call this after setting up a set of new monitors. If monitored information is available for retrieval, it will retrieve the monitored data from the Status Server and either call the client registered callback function or store the information in the memory locations whhich were previously defined during the setup of the monitor.

If a monitor request was made to monitor as an Integer, floating point, or boolean data types, a conversion will be performed from the string format received over the interface to the monitor requested data type. Any errors detected, either during the conversion process or from the data response sent by the Status Server, will be stored in the previously allocated memory location for return code information.

Call syntax


    PASSFAIL ssSync(void)

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.21 ssPwd() - Retrieve the current working directory path

This routine will retrieve the current working directory path for the client from the Status Server. The default path used by a client upon connection to the Status Server is ``/''. This will be the path returned by this routine unless the client has explicitly change the working path through a call to ssChdir().

Call syntax


    const char *ssPwd(void)

Return value

This function will either return the current working directory path or NULL in case of an error. If the function should return NULL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.22 ssChdir() - Change the current working directory path

This routine will change the current working directory for the client on the Status Server. The default path used by a client upon connection to the Status Server is ``/''.

Call syntax


    PASSFAIL ssChdir(const char *path)

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.23 ssRmdir() - Remove a directory from the Status Server

Once a successful touch has been performed on a directory, it is possible for the client to request the removal of the directory from the Status Server.

The directory cannot be completely removed from the Status Server until the use counts for the directory are zero. This means that no clients currently have an outstanding touch, monitor, or directory listing on the directory. If the use counts are greater than zero, the object will be put in a state of ``NONEXISTENT'' and will be removed whenever the use counts become zero.

Call syntax


    PASSFAIL ssRmdir(const char *path)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.24 ssOpenDir() - Open a Status Server directory for reading

When performing a directory listing, a Status Server directory must first be opened for reading. If the directory can be successfully opened, all the underlying contents can be retrieved by making successive calls to ssReaddir. Information from multiple directories can be retrieved by using the same regular expression matching rules used by the UNIX ``ls'' command.

Call syntax


    PASSFAIL ssOpenDir(const char *path)

Input parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.25 ssReadDir() - Retrieve the next directory listing object

This routine will retrieve the next directory line if a directory has previously been opened for reading. Upon successful completion a populated ss_dirent_t will be returned back to the client.

Call syntax


    const ss_dirent_t *ssReadDir(void)

Return value

This function will either return a populated ss_dirent_t data structure, or NULL. If the function should return NULL, there are two reasons why this could occur. First, there are no more directory lines to be read. Secondly, an error occured. If the function should return NULL, the ssGetError() function must be called to determine if an error occured. If ssGetError() returns SS_NO_ERROR, the directory contents specified in the ssOpendir() function have all been retrieved. If ssGetError() is not SS_NO_ERROR, these are the possible error conditions why this routine may fail:

4.26 ssGetFileDescriptor() - Retrieve the socket file descriptor used to communicate with the Status Server

Call syntax

This routine will return back the file descriptor used for socket communication with the Status Server. As a result, the client could use the file descriptor within a select loop in order to be informed when the Status Server sends something to the client. This is particularly useful for a client which has placed monitors on Status Server variables.

Caution must be used when using the file descriptor. If it is used incorrectly, the socket communications between the client and Status Server may be adversely affected.


    PASSFAIL ssGetFileDescriptor(int *fd)

Output parameters

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.27 ssTraceOn() - Turn on tracing within the Status Server

This routine turns on the tracing of all Status Server activity on the server itself. Please be VERY CAREFUL when using this option, since tracing will seriously affect the performance of the Status Server and could flood the CFHT_LOG.

Also, once tracing is turned off, it will stay on until it is turned off with the ssTraceOff() function call. It will not be turned off automatically when the client who requested it disconnects from the Status Server.

Call syntax


    PASSFAIL ssTraceOn(void)

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.28 ssTraceOff() - Turn off tracing within the Status Server

This routine turns off the tracing of all Status Server activity on the server itself. The client which initiated the trace with the ssTraceOn function call does not need to be the client which requests the tracing to be turned off.

Call syntax


    PASSFAIL ssTraceOff(void)

Return value

This routine will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.29 ssAutosave() - Initiate a serialization of the Status Server

This routine triggers a serialization of the Status Server data contents to a text file. The location of where the serialization text file is stored can be found by looking at the value of ``/proc/serialize/filename''. A serialization of the Status Server is also performed periodically at the interval specified by ``/proc/serialize/interval''.

Call syntax


    PASSFAIL ssAutosave(void)

Return value

This routine will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.30 ssWait() - Wait for a period and, if available, retrieve mirror updates

This routine allows for a timeout to be supplied which indicates how long the timeout interval should be on a select() call when waiting for activity to occur on a socket. If activity occurs on the socket, it will initiate a check whether any mirroring information is available for retrieval by the C API. If so, the mirroring data will be retrieved and the client registered callback function will be invoked.

Call syntax


    PASSFAIL ssMirrorWait(int timeout_hundredths)

Return value

This function will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:

4.30.1 ssMirrorCallback() - Mirror a Status Server and be informed of any changes via a callback

Following an ssMirrorWait() API call, if an object or directory changes on the Status Server, a mirror update transaction will be passed to a user callback function.

Call syntax


    PASSFAIL ssMirrorCallback(ssMonitorCallbackFunc userfunc),

Input parameters

Return value

This function should always return PASS when called via the client API. If a failure should happen to be returned, this should be considered an internal error within the Status Server API library. At this point, the client API library will initiate an abort() causing a segmentation fault to occur.

4.31 ssShutdown() - Shutdown the Status Server

This routine will initiate a serialization of the Status Server data followed by a shutdown of the server itself. This is a disruptive operation and will affect all clients currently connected to the Status Server. As a result, the utmost discretion must be used to determine when the routine should be used.

Call syntax


    PASSFAIL ssShutdown(void)

Return value

This routine will return either PASS or FAIL. If the function should return FAIL, the reason for the error will be an enumerated type returned by the ssGetError() function. The error types which are possible when calling this routine are:


next up previous contents
Next: 5. Examples Up: Status Server Client C Previous: 3. API Primer   Contents
Tom Vermeulen
2008-02-07