Server-initiated synchronization is much easier to set up Enhancements have been made to make it much quicker to set up a server-initiated synchronization application:
Sybase Central support Notifiers and Listeners can now be set up in Sybase Central Model mode, allowing a subset of useful Notification services. In Model mode, you identify a table for server-initiated synchronization, and your download_cursor is automatically used to determine what data is used for notification purposes. When data identified in your download cursor changes, a Notification is sent. The Deployment wizard generates a corresponding Listener options file.
See Setting up server-initiated synchronization in a synchronization model.
New default gateway A new gateway called the SYNC gateway allows you to make a persistent connection over the same type of communication path you use for MobiLink synchronization. The SYNC gateway is now the default device tracker gateway, meaning that notification will first try the SYNC gateway, with fallback to the UDP and then SMTP gateways.
Shared connections Multiple Notifiers can now share the same database connection, reducing contention and required server resources in the consolidated database.
See Notifier events.
Notifier uses character set of remote device Notifications are now sent to the remote device using the character set of the remote device. Device tracking information is translated before being applied to the consolidated database.
Custom confirmation handling You can now implement a Notifier property in SQL that processes the confirmation of a push request and returns its status.
Custom error handling You can now implement a Notifier property in SQL that processes errors such as when a push request is not delivered, not confirmed, or improperly confirmed.
See error_handler event.
Persistent connections The Windows Listener now supports persistent connections. By default, the Listener now maintains a persistent connection to the MobiLink server for device tracking, notification, and confirmation. This feature provides significant performance enhancement over previous versions. It can be disabled with the dblsn -pc option.
New or changed Windows Listener options The Listener now supports the following options:
Option | Description |
---|---|
-ni | Stop tracking UDP addresses when -x is used. Previously, this was called -g. |
-pc{+|-} |
Enable/disable persistent connection for notifications. |
-ns | Disables default SMS listening on Windows Mobile 2003 and later Phone Edition. |
-nu | Disable default UDP listening. |
-r | Register the remote ID file for use by the $remote_id variable. |
-v | When set to 1 or above, the verbosity option now displays and logs command line options. |
Remote ID file On the Listener command line, you can now access the new MobiLink remote ID (which by default is a GUID) using a remote ID file. You do this with the new dblsn option -r and new Listener action variable $remote_id.
See MobiLink Listener utility for Windows devices (dblsn) and MobiLink Listener action commands for Windows devices.
New Listener action variables for authentication There are new action variables that are useful in message handlers: $ml_user and $ml_password.
New Listener action variable for connection parameters The new $ml_connect action variable expands to the MobiLink connection parameters that were specified with the dblsn -x option.
Listener now uses ISO 8601 datetime format for message timestamps
Timestamps in informational, warning, and error messages now use the unambiguous ISO 8601 datetime format: {I|W|E}.yyyy-mm-dd hh:mm:ss message
.
Listener can use TLS The Listener can now connect to the MobiLink server using all the network choices as other MobiLink clients. This allows you to apply security to device tracking and notification.
See -x in MobiLink Listener utility for Windows devices (dblsn).
Discuss this page in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |