Jan 09, 2009

An Overhaul of Transaction Flags: Where 6 = 1

by Tod Beardsley

BreakingPoint users have no doubt noticed we just updated our Application Simulators, including a new implementation of transaction flags (login in to Member's Access above to download the latest Strike & Application Protocol Pack). I wanted to take a second to outline the reasoning behind transaction flags, where they were prior to this update, and why they can really help in simplifying your testing and reducing the time it takes you to test.

The "Old" Way

When running a network application, most of us have well established notions of packets and sessions. Packets contain application data and have well-defined lengths and attributes (TCP or UDP headers, 1400 bytes or 100 bytes of data, etc.), while sessions are groups of packets flowing between a client and server, book-ended by the session setup and tear down (in the case of TCP) or just the beginning and end-of-data (for UDP). In our Application Simulator, we also have this idea of a "transaction," which is a self-contained subset of packets, part of a larger session. Since they're an abstraction and can be somewhat arbitrary, we created transaction flags to mark these transactions so BreakingPoint users could track statistics on whichever unit-scale is meaningful for them.

Let's use HTTP as an example. A traditional "HTTP transaction" might be a GET request of some URL, followed by a "200 OK" response with some HTML data. In the real world, however, most HTTP GETs and 200 OKs come in clusters. A user's browser might fetch a page that has a few images and a couple style sheets associated with it. To accurately represent this as one transaction, you'd want to set a "start" flag on the GET, an "end" flag on the last style sheet response, and leave everything in the middle as a "continue." This might be important for whatever you're testing -- you'd want to see how many of these more realistic transactions completed successfully, versus the more technical packet or session failure counts.

We also have this idea of a "startend" transaction, where a single action is the entire transaction -- a simple example of this is in the discard protocol, or a keep-alive ping that you don't expect a response to. A client sends some data... and that's it.

Welcome to the New Way

That is how transaction flags have worked for a while in BreakingPoint's application model, and it's easy to grasp when each action represents a single event from a client or server. But as time went on, we started introducing more complicated applications. Take Oracle -- it features a stupendously complex authentication protocol that would be a huge hassle for users to implement by selecting actions in the right sequence. So, a simple "login" action was created that bundles up all this back-and-forth business. Unfortunately, at the time, this ease-of-use meant sacrificing user-configurable transaction flags.

For a while, this was generally acceptable -- most of the time, these single-button application events like "login" and "chat" and "play WoW" were natural transactions. However, the fact that users could customize the transaction stats for some apps, but not others, got more and more uncomfortable for us. After all, as far as the user was concerned, there's no difference between a simple and a complex action, and getting stuck with twenty transactions when you really just wanted one seemed pretty lame.

So, over the last week or so, we've brought the idea of configurable transactions back into all our Application Simulations, regardless of the single- or multi-packet nature of the actions themselves. Now, users can group a bunch of database select statements and their results together into a single transaction, or a sequence of MSN instant messages, or BitTorrent data chunks, or what have you. This makes for more realistic statistical reporting on application flows, a more consistent UI, and less ambiguity in what a "transaction" means to both users and us protocol developers. But, most importantly -- at least for me -- this architectural change in how we handle these flags means I can close out six related feature requests in one fell swoop.