Each collector interfaces with a specific Feed/Platform pair it is built to handle.  (Typical installations of our server interface with only one Feed/Platform, but the technology is designed to support multiple collectors.)

Each collector accesses live data from its corresponding Feed/Platform, filters the data (a critical step in this process), and re-transmits the data to the Repo Server in a standardized format for writing to the Repository.  If so configured—and admissible by the Feed/Platform—the collector also republishes data that passes the filter test to the Feed/Platform.

To convert data to the standardized format, the collector must organize it using Feed-specific logic for determining the kind of instrument, the nature of the update, the critical fields that must be parsed, and the internal dependencies between fields which must pass logic tests to make sure the data is valid for writing to the Repository.

This logic becomes increasingly complicated when dealing with expiring instruments and futures.  For example: when converting bond future data to the internal standard format, the collector may need to access cached information for other symbols to determine the cheapest-to-deliver underlier.  The collector attempts to collect all information regarding the price update—as far as possible—from the Feed it is built to service.

As mentioned above, the Olsen Data Server is designed to handle multiple Feed/Platform interfaces, and each interface needs to be supported by its own collector process to handle the unique logic (of internal relations between symbols) of the interface in question.