9/8/2006 
Changes for 2.3.0:

• Added "its.app.SddReplay", an application for re-transmitting previously recorded Sdd streams.
• Fixed ";;" syntactical error in "its.backbone.sdd.SddReceiver.java" that prevented compilation under java 1.4.
• Fixed bug in support code for "its.app.trans.SddTranslator" that prevented translation of legacy data records where bytes are to skipped at end of record.
• Updated "AvlConfig.txt" to reflect current metro AVL data format.
• Supplied compilation instructions for the apps.
• Regenerated the javadocs.

2/24/00 

This release contains two tools that can help to integrate SDD with an existing system:

1. ItsFrame.c, a library of C functions to send a stream of arbitrary data types over a socket connection to an ItsFrameReceiver. This standardizes and streamlines the necessary interprocess communication to pass data from a C program to the SDD java library.
2. SddTranslator, a program that can be configured to read a stream of arbitrary data types and translate them into an equivalent SDD stream. When combined with a data source that uses ItsFrame.c, SddTranslator allows the creation and configuration of SDD streams without any java programming.  SddTranslator is found in the its.app.trans package, along with several example configuration files.

A new section in the SDD Software Manual describes how to use these components to get an SDD stream up and running.

10/29/99

Overview

SDD Transmitter changes

When designing a new data stream, the frequency of transmission of data frames must be estimated. It's now possible to encode this information in the data stream so that receivers can understand the intended frequency. See the new method SddTransmitter.setTimeout.

The new method SddTransmitter.startPulse can be used to automatically add "pulse" frames to the data stream.  These are zero-length data frames, and they will be sent after a given time elapses with no new data.  These simplify the creation of a stream in which a large data set in the Contents frame is updated infrequently.  Using startPulse also improves any transmitter whose data source might go offline periodically, because it prevents downstream clients from reconnecting needlessly when the data stream is quiet for a while.

The new exceptions MissingContentsException and MissingSchemaException must now be handled when updating current frames.  These exceptions formalize the order in which frames must be created.

The SddTransmitter class now parses data frames before sending them.  This feature can be disabled if an application-specific data frame format is being used.

As always, SddTransmitter automatically generates the serial numbers that identify Schema, Contents, and Data frames. However, the Schema and Contents serial numbers are now stored in a properties file generated by SddTransmitter, so that if the program is restarted and no actual change has occured in the Schema or Contents, the same serial numbers can be used. This gives any receiver of the stream the knowledge that a change in a serial number always indicates a change in the Schema or Contents. The API reveals this new behavior only by an additional parameter in the SddTransmitter constructor that allows the programmer to name the properties file.

Potentially hundreds of clients can connect to an SDD Transmitter or a Generic Redistributor. When a client goes away, the server notices its absence the next time it attempts to send data to the client. This works unless the data stream is down and there is no new data for a long period of time. The server-side connections are now monitored to determine when clients have disappeared, which they may do automatically due to their reconnection logic. This increases the long-term reliability of a Transmitter or Redistributor.

SDD Receiver changes

The SddReceiver base class now monitors the timeout value which may be present in an SDD stream, and sets its client socket timeout accordingly. When this amount of time has elapsed without receiving any new data, a new connection to the server is built. Formerly, the timeout value was always set at 30 seconds. This default value has changed to 90 seconds. These changes are intended to reduce the chance that a connection will be rebuilt unnecessarily. The SDD protocol ensures that no harm is done when this does occur, and the reconnection behavior is desirable because it is the only way to detect certain types of network failures. Please note that the reconnection feature is still configurable, and may even be disabled, via the method ClientConnection.setTimeout.

When SddReceiver builds a ContentsData object for an incoming data frame, it now strips single quotes from quoted strings. This has always been the behavior for tables originating in the contents frame, and the functionality is now the same no matter where the ContentsData object was built. To print data contained by a ContentsData object, the new printRowString method automatically handles different output formats.

Some confusion was caused by a warning message that could be generated by the FrameQueue object when more than 100 frames were waiting to be processed. This warning message is now better documented and configurable; see the method FrameQueue.setWarningLimits. The message helps developers of SDD Receiver programs determine how the processing time they require relates to the incoming data rate.

The BadTypeException is no longer thrown by methods in the ItsFrame class.  This exception arose if the "type" field of an ITS Frame was not among the handful of pre-defined, generic frame types.  With the elimination of this rule, it is now possible to receive frames with application-specific values in the "type" field, if necessary. 

Further performance gains have been realized in the SDD receiver.  The receiver's most time-consuming task, creation of a ContentsData object, is now 2 to 5 times faster, which means less of a delay before the application can process incoming real-time data.  Also, a thread-safety problem has been resolved, enabling multiple receivers to be in use within the same program.

Changes to enable creation of SDD Operators

Note that it is necessary to make a copy of a data stream's Schema object before modifying it, because the Schema object is continually used to guarantee the integrity of incoming data.

New example programs and utility classes

its.app.SddFilter illustrates how to write an SDD Operator, and provides a generic facility for filtering on any value in any data stream.

SDD Java API Release 2.0.0

3/7/99

Overview

Applications ready to run: the its.app package

Formerly known as either "Fanout" or "GenericRedistributor", the standard application for receiving and transmitting an SDD stream is now called Redistributor.

The bin directory

The doc directory

Package reorganization

New Receiver programming model

SDD and firewalls

ErrorLogger

09/02/98

Overview

In this release, SDD parsing functionality is enabled in the receivers. The receiver will exit if it detects a poorly-formed schema or contents frame. This is an important step towards enabling creation of SDD transmitters for new data sources.

Bugs fixed

• In the receiver, when a new data frame arrives, it is passed to the extractor along with an "offset table" that describes where to find the data for each sensor. This offset table comes from the contents frame. In the case of traffic data, the offset inforamation is in the table called LOOPS. When a new contents frame arrives, the offset table should be regenerated, but in former releases it was not. So, the extracted data might not have been correct after the receiver had been running long enough to receive an updated contents frame.
• When the receiver performs automatic data extraction, error messages would appear if table names in the schema or contents were not all upper case identifiers. Code in the SQL package has been updated to properly perform case-insensitive comparisons.

Other changes

• The two receiver implementations, SddAutoExtractReceiver and SddDatabaseReceiver, are now part of the its.app package. Once its.zip is on the classpath, the receivers are run using the command "java its.app.SddAutoExtractReceiver".
• The its.zip file in the lib directory now contains the classes formerly distributed in runtime.zip. It also contains the source code formerly distributed in src.zip.

03/1/98

• Changes to the Event Model. The 1.0 event model contained separate callbacks for SchemaEvent, Content(s)Event, DataEvent, ExtractorEvent, and SerialNumberEvent. These events, residing in its.backbone.sdd, all extended SddEvent. There was no explicit tie between the serial number event and its underlying SDD event - an important omission. 1.0 did not have any way of accessing exceptions thrown by SddReceiver. The 2.0 event model remedied this problem by modifying SddEvent to take a serial number as one of its constructor arguments. This SN can subsequently be accessed via the getSerialNumber method. These changes were propagated to the sub class events: SchemaEvent, ContentEvent, ExtractorEvent, DataEvent, and ExtractedDataEvent, all of which extend SddEvent in its.backbone.sdd. 2.0 dropped the ambiguous SerialNumberEvent, SerialNumberListener, and its callback method, serialNumberReceived. The other events retained their older constructors, but these were deprecated to alert the users to the change. 2.0 added the domain level ExtractedDataEvent and its listener, ExtractedDataListener. The 2.0 event model was also enhanced to include exception handling. Registered observers can now catch exceptions thrown in SddReceiver by evoking the event's getException method in the overloaded callback routine. If an exception is produced by the SddReceiver, getException will cause it to be thrown in the callback. Code that ran against the old 1.0 callbacks will need to be modified as follows:
  1. Remove all references to serial number events, listeners, and callbacks.
  2. To obtain serial number information, access the other events and evoke their getSerialNumber methods.

  To utilize SddReceiver exceptions, see the example below for schema callback:

  public void schemaReceived(SchemaEvent event) {

  try {

  event.getException(); // will throw exception if one was produced

  // other code

  }catch(Exception e) {

  // handle the exception

  }

  }

• The SddReceiver has two new event callbacks: extractorReceived and extractedDataReceived. Both stem from a technology that leverages the JAVA ClassLoader capabilities. The former returns an extractor, a JAR formatted collection of class files containing a DataFactory, that allows the receiver to decode BLOB data into structured classes that emulate populated schema tables (see its.backbone.domain.DataFactory hyperlink). Since each data flow contains its own extractor, the receiver will be able to perform the decoding for all available Sdd data types. The latter callback returns those extracted structures, freeing users from having to perform the decoding themselves. We feel that this generic, domain independent capability will greatly enhance the ease-of-use of SDD.

• New applications (see Section 3). Our applications in the its.app package (especially SddAutoExtractReceiver) provide users with a simple tool that will allow them to connect to and configure incoming data from all available SDD data sources.

• A new its.SQL package, containing classes and methods that allow users to program and manipulate data at the schema level, including JDBC interactions against their DB host.

• Extensive, revised JAVADOC documentation describing the API and its packages.

• New, simplified directory organization that emulates a more conventional JAVA structure. The release provides all the class files in one easy-to-install zip file.

ITS Backbone | Current Software Library | Software Archive | Supporting Documents | ITS UW Home Page | SmartTrek Home Page