FIX  protocol is the industry-driven messaging standard that is primarily deployed by global financial services sector to transact and conduct business efficiently with the least latency.  The mission of FIX is “To improve the global trading process by defining, managing, and promoting an open protocol for real-time, electronic communication between industry participants, while complementing other industry standards.” Even though FIX standard’s intentions were geared towards seamless automation of the exchange of time-sensitive trading data, almost all FIX implementations use a static/manual process for FIX application connectivity.

Recent conversations with a financial services firm focused on the following pain points relating to OpEx and lost business

  • Manual process is error prone
  • New service creation is cumbersome, every customer/client is given a seperate  IP address and TCP Port.
  • Changes in networks/firewall infrastructure does not account for static pinholes
  • Low Latency is being achieved at the cost of security.

For instance when a client requests a FIX service a static internet TCP/IP endpoint is assigned and (added to the excel spreadsheet ..yes  this is true !!) the corresponding server TCP/IP endpoint is also noted down. Any changes to the FIX service involves several maintenance windows because the change spans firewalls, routers and application servers. FIX is currently designed for point-to-point communication between two FIX systems with optional support to handle one system representing multiple firms via the same FIX connection.

FIX protocol message consists of several such  <TAG>=<VALUE><DELIMITER>  in ASCII format.  FIX  identifies customers based on TargetCompID (tag 56), SenderCompID(tag 49) and OnBehalfOfCompID (tag 112).  Each unique session can be defined by any one of the identifiers mentioned above or a combination of them.

NetScaler with its powerful content switching capabilites can parse FIX messages and extract the  TargetCompID  as shown below as part of the Content switching policy for TCP VIPs:

The FIX message contains ^49=VENDOR^

add cs policy fix_protocol -rule client.tcp.payload(100).typecast_nvlist_t(‘=’,’^’).value(“49”).set_text_mode(IGNORECASE).eq(“vendor”).

This is typecasting the first 100 bytes of the TCP ASCII byte stream to name value pairs separated by “^”, “=” and finding the case ignored SenderCompID to match against.

The content switching based approach allows the customer to control which SenderCompID has to be serviced by what vservers.

Loadbalancing FIX protocol on the NetScaler which acts like a FIX gateway brings along these benefits:

  • Single IP address/TCP port to all of the clients- No more firewall config changes when adding new clients.
  • Seamless management of the FIX servers with superior HA and health monitoring.
  • Manual process of client addition/deletion is reduced significantly.
  • SYN attack protection for all of the FIX Servers.
  • NetScaler high performance TCP offload provides for low latency.

With the upcoming 9.3 enhancement release, NetScaler also supports TCP rule based persistence with the above mentioned rule on a TCP VIP without the need for content switching policies. With rule based persistence if all of the FIX servers are identical and can serve any of the clients, NetScaler will use the SenderCompID or any such FIX fields as a persistence method and further simplify the configuration.