blast from the past on reliable communication 3336

Anne & Lynn Wheeler

My one comment:

I come from a deep real-time background. If someone starts tabulating interrupt latencies or bandwidths, that's something I can immediately bite into and begin grokking the application with. The Navy numbers above are a pretty good example.

OTOH, I now get to see (if not really define) financial networks and their "real-time" latency vs bandwidth vs reliability vs line cost requirements. Even though I've been trying for a year at this now, I still have little understanding of where the numbers and requirements come from. I mean, in a real-time system I certainly understand that "data will be lost" if latency requirements aren't met, and I understand that "airplane will be lost" if other requirements aren't met. Yet in the financial world many of the deadlines are more synchronization requirements (i.e. it's OK to delay several hours as long as you make it for reconciliation before somebody ELSE's deadline.)

In the real-time world I was in, if you didn't have the data by a certain time, it just didn't matter anymore. If it came in later it was stale data and had little significance to the application at hand. (Although from a historical debugging persepctive it was often interesting to at least log.) OTOH in financial applications it is NEVER ok to just drop data on the floor because it's a little stale. In fact the handling of stale data and reconciliations is where most of the effort ends up being.

In my real-time work, the applications where the timeliness of response was so vital that data more than a few milliseconds old simply didn't matter anymore were the most interesting. But in the financial world you never just throw away old data: in fact as far as I can figure out it pretty much all has to be kept in storage (somewhere) for years.

Tim.