More server maintenance

, ,
1

Imported from previous forum

2

Hi,

Asking lots of questions, I know. But here is the laundry list of items that we have gotten from various vendors on the regular maintenance of the server:

Server monitoring
Message monitoring
Creating and maintaining routing rules per connection
Testing and release of FIX engine upgrades
Establish connections with broker through direct lines, routes, and firewall rules
Run the EOD process, which consists of archiving and clearing logs for preparation of the next business day.

Are these valid? Are we missing anything?

Your help is greatly appreciated.

Best regards,
Melissa

3

[ original email was from tushar deshpande - tushar.deshpande@citigroup.com ]
i didn’t see the earlier mesg in this chain(if any). replying based on this message alone. plz see inserts marked with ## in the text below.

Hi,

Asking lots of questions, I know. But here is the laundry list of items
that we have gotten from various vendors on the regular maintenance of
the server:

Server monitoring

does “server” imply the machine that runs your FIX engine? if yes, you may want to check with your local SAs about industry-standard solutions to monitor the disk-usage, cpu, swap-space, etc on the server.

if you mean the FIX process by “server”, you could use monitoring solutions like ITRS for process monitoring.

Message monitoring

certain third-party vendors provide tools to monitor FIX messages(e.g. TTmonitor provided by Transact-Tools).

Creating and maintaining routing rules per connection

this is strictly not part of the FIX protocol. routing has 2 components: the criteria to route on, and the transport parameters used for the actual routing. e.g. you could route based on symbol-range of the incoming orders. the underlying transport used(e.g. TCP/IP) controls how the actual routing will happen. can you elaborate as to what you are looking for in the routing area?

Testing and release of FIX engine upgrades

this effort could vary depending on the version you are going to upgrade to. e.g. if you are upgrading from FIX 4.0 to 4.1, you also need to look at the ExecType in the incoming responses(4.0 does not support the ExecType field in the responses). i have typically seen sell-side willing to support both FIX versions(sometimes on the same session) for backward compatibility till the buy-side is ready to cleanly migrate to the new version.

Establish connections with broker through direct lines, routes, and
firewall rules

this is again not really part of the FIX protocol. you need to talk with your level-1 networking team to decide how the logical FIX connections map onto the underlying hardware/routes(e.g. 5 FIX connections could use the same underlying T1 line, etc).

Run the EOD process, which consists of archiving and clearing logs
for preparation of the next business day.

you could fire a job from a daemon(e.g. cron on UNIX) that archives the cache files of the FIX engine. the key is to reset the outgoing and incoming FIX sequence-numbers to 1 before the start of the next business day. be careful to not delete the cache if you also handle orders that could live over several days(e.g. if a GTD order).

Are these valid? Are we missing anything?

other things that you could look at:

  • volume of the messages processed(and hence the need to scale)
  • pre-market queuing
  • resiliency(what happens if the process or the hostname crashes intra-day, etc)
  • admin functionality(e.g. ability to internally cancel orders electronically if you know that the cancels happened on the exchange but could not be sent over electronically due to network issues, etc)

Your help is greatly appreciated.

Best regards, Melissa

4

I believe Tushar covered a lot of the key points. You may also want to consider fat finger rules / limits so that you will not have erronous orders.

Regards,
TK

i didn’t see the earlier mesg in this chain(if any). replying based on
this message alone. plz see inserts marked with ## in the text below.

Hi,

Asking lots of questions, I know. But here is the laundry list of
items that we have gotten from various vendors on the regular
maintenance of the server:

Server monitoring

does “server” imply the machine that runs your FIX engine? if yes,

you may want to check with your local SAs about industry-standard

solutions to monitor the disk-usage, cpu, swap-space, etc on the

server.

if you mean the FIX process by “server”, you could use monitoring
solutions like ITRS for process monitoring.

Message monitoring

certain third-party vendors provide tools to monitor FIX

messages(e.g. TTmonitor provided by Transact-Tools).

Creating and maintaining routing rules per connection

this is strictly not part of the FIX protocol. routing has 2

components: the criteria to route on, and the transport parameters

used for the actual routing. e.g. you could route based on symbol-

range of the incoming orders. the underlying transport used(e.g.

TCP/IP) controls how the actual routing will happen. can you

elaborate as to what you are looking for in the routing area?

Testing and release of FIX engine upgrades

this effort could vary depending on the version you are going to

upgrade to. e.g. if you are upgrading from FIX 4.0 to 4.1, you also

need to look at the ExecType in the incoming responses(4.0 does not

support the ExecType field in the responses). i have typically seen

sell-side willing to support both FIX versions(sometimes on the

same session) for backward compatibility till the buy-side is ready

to cleanly migrate to the new version.

Establish connections with broker through direct lines, routes, and
firewall rules

this is again not really part of the FIX protocol. you need to talk

with your level-1 networking team to decide how the logical FIX

connections map onto the underlying hardware/routes(e.g. 5 FIX

connections could use the same underlying T1 line, etc).

Run the EOD process, which consists of archiving and clearing logs for
preparation of the next business day.

you could fire a job from a daemon(e.g. cron on UNIX) that archives

the cache files of the FIX engine. the key is to reset the outgoing

and incoming FIX sequence-numbers to 1 before the start of the next

business day. be careful to not delete the cache if you also handle

orders that could live over several days(e.g. if a GTD order).

Are these valid? Are we missing anything?

other things that you could look at:

  • volume of the messages processed(and hence the need to scale)
  • pre-market queuing
  • resiliency(what happens if the process or the hostname crashes
    intra-day, etc)
  • admin functionality(e.g. ability to internally cancel orders
    electronically if you know that the cancels happened on the exchange
    but could not be sent over electronically due to network issues, etc)

Your help is greatly appreciated.

Best regards, Melissa