Network Computingwww.networkcomputing.com

Maybe You Have A Case Of The BLOBs

When I was a boy, I went to the movies to see Steve McQueen spray liquid oxygen at a huge red gelatinous alien beast, the Blob. The Blob grew larger as it attacked and ate its victims. In a similar way, data BLOBs not only eat network bandwidth, but network storage space, too.

BLOBs, or Binary Large Objects, are big single files of noncharacter data. BLOBs include graphics files, still images, sound files and other data types that don't have any "normal" identifiable characters.

Where do BLOBs come from? Sound boards, scanners and fax servers have spawned BLOB sightings on networks everywhere. Graphics -- once vices and now habits -- can dim network bandwidth in ways that network designers plainly didn't conceive of even three years ago.

Identifying Symptoms

A third method (and a better way of dealing with the water) is to shrink it, say, by compressing it; methodologies are explained later.

Inside the BLOB

There are some types of noncharacter data that aren't typically thought of as BLOBs but still qualify. Those include files made from video streams and other data types that need their own timing or are timed together. Data types needing their own timing are referred to as isochronous data. Isochronous data must be timed together; they use a timing reference that's external to the normal timing of network flow controls; the standards are a function of the standards associated with a the medium through which the analogized data that comprises multimedia objects. For example: Video timing is controlled by the Society of Motion Picture and Television Engineers (SMPTE). Interrupting an isochronous data stream by normal network events can prevent correctly timed data delivery.

Other BLOBs

Think of blobs as large files of noncharacter-based data. Humongous files of any kind of data can be BLOBs, but the "Object" part of the term usually defines data considered to be an aggregation or object, and the "Binary" part tends to connote noncharacter or nontokenized data.

How Big the BLOB?

BLOBs are compressed at the source or interface to the PC at the time they become digitized. Two kinds of compression are popular: Software compression that uses the workstation's CPU to do the work of compression, and hardware compression that uses a Compression Decompression Chip (CODEC) or silicon equivalent to off-load data compression from the workstation's CPU. Hardware compression helps in workstation configurations without multitasking vastly, and it will become ubiquitous downstream.

BLOBs can be compressed from as little as 4:1 to as much as 200:1, depending on the data type and how the data lends itself to compression algorithms. Compression higher than 50:1 is tough to achieve without quality and/or fidelity loss. Large standards bodies, notably the IEEE and ANSI/ISO, have come together to agree on different compression standards for data interchangeability and repeatability. (See "Bigger And Bigger BLOBs," above.)

Caging the BLOBs

BLOBs have traditionally been tagged with other character-based identifiers, and stored as separate entities or in databases that can accommodate the fatuous data sizes associated with BLOBs. Now, they live inside, and within the next few years, products like Oracle's Media Server should be able to recognize the objects (like a brown pair of shoes) in BLOBs in the same way that optical character recognition (OCR) software discerns characters from a scanned document. Say thank you to NASA satellite object recognition technology.

Indigestion

BLOB-making software -- especially imaging workstations that store directly to a network -- must be carefully controlled. It's for that reason that very high-traffic workgroups are often purposely isolated from other networks and their traffic. That means using purposefully independent network segments, high-speed network cards, lots of workstation and file server driver tinkering, and the best compression values that can be tolerated.

BLOB traffic today is usually localized to a specific workgroup or LAN. The large amount of data (even with compression) makes communicating BLOBs across a distributed network or WAN expensive.

In the NetWare world, several different methods help BLOBs make it through the network garden hose efficiently when the water cannot be shrunk anymore. Packet Burst and Network Least Shortest Path (NLSP) protocols allow long streams of data -- which are what BLOBs are made of -- to be transmitted most efficiently. Packet switch/forwarding devices (Kalpana, SMC, Lannet and so on) can also redistribute network bandwidth to free up traffic on individual network segments. The larger the network bandwidth, the smaller the background traffic, and the largest, supportable packet sizes will increase BLOB throughput.

But the best place to start taking control of BLOBs is at their source, where BLOBs can be compressed to their smallest usable form. Find the best usable compression that still allows flexible, timely access to the data that the BLOBs represent. Compression at the workstation pays off in numerous ways: less data to transceive, less overall storage tax, more workstations per network segment, less cost to transceive BLOBs over WANs.

Graphical user interfaces and the general public fascination with multimedia objects mean that BLOBs won't go away. Planning for high network utilization by workgroups pays off handsomely when inventive and creative types get interesting ideas. Reinventing network response is one of the most expensive of network costs.

Standards are crucial. Although localized networks can stand a bit of anarchy, there are problems in sending incompatible formats through an enterprise network, where a third format is often created as an intermediate data type.

This leads to a problem called Alice's Restaurant Syndrome, where everyone has lots of storage space and never needs to take out the trash until the area reeks of rotting data. Then you may need to call in a virtual Steve McQueen and have him freeze up the growing BLOBs with some liquid oxygen of your own.

Tom Henderson is vice president of engineering for Unitel, of Indianapolis, IN. He can be reached at 76711.737@compuserve.com.