Random Thoughts on Software

I’ve been looking around for a decent way to work out of an encrypted file system. I’ve come to learn that such systems are called On-The-Fly Encryption (OTFE) systems. The one that appealed to me the most was an open-source project called TrueCrypt.

TrueCrypt allows you to create encrypted “volumes” and map them to Windows drives. The tool will prompt you for your encryption password when you try to mount a volume. A volume can be a hard-disk partition, USB stick, floppy disk, or a file. The file-based volume (a.k.a. container volume) is great because you don’t have to format a device in order to have an encrypted volume. The file can exist in an otherwise unencrypted file system and TrueCrypt will map the volume data contained within the file to a Windows drive.

There is no way to identify a TrueCrypt volume as it has has no file signature or required extention. For file-based volumes, you can call the file whatever you want and store it where ever you want. If you open up the file, it look like a bunch of random data.

One really cool feature is the ability to create a hidden volume (a volume within a volume). When you go to mount your TrueCrypt volume, if you type in your outer-volume password it mounts your outer-volume, and if you type in your inner-volume password it mounts your inner-volume. They refer to this as plausible deniability. If somebody forces you to provide an encryption password, you provide them with the password for the outer-volume, which has a set of files that look important, but really aren’t (red-herrings so to speak).

Another cool thing is that you can encrypt the volume using multiple encryption schemes. So if somebody does happen to crack the encryption scheme itself, you still have additional layers of security.

Even though I’m tech-savvy, I always have a lingering feeling that somebody may have bypassed all of the security measures I have in place on my network at home and may be rummaging through my personal records and private files. With OTFE I feel much more confident that I can keep my personal documents private.

The next time you are responsible for naming something, be it a software product, an organization name, a brand of clothing, or whatever, please keep this in mind: people will probably want to search for the name of your “thing” on the Web.

It is really annoying when I Google for spring factory and I don’t get anything remotely close to what I am looking for in the first two results pages. The phrase spring framework factory definitely does better, but I hate having to type framework everytime I want to search for something that has to do with Spring. I don’t have to do this with JAXB, Sony, Google, or Exxon.

Now, I can’t say that names like Windows and Apple are poorly chosen because they have been around since before Web search engines really existed and they also have tremendous mindshare. If you search for Windows online, you seem to find more results related to the Windows software platform than results related to companies that sell actual windows.

I know that this problem exists for any word that has overloaded meanings. All I’m saying is that people need to consider this as a factor when they go to choose a name. Acronymic or hard-to-spell names are annoying, but so are “overly-overloaded” names.

There is an art to picking a good name. Be an artist.

It is important to realize the differences between synchronous and asynchronous systems.

A synchronous system is one that you make a request to and wait for a response back from. Examples include a database, a Web server, a method call, a voice telephone call.

An asynchronous system is one to which you send a request and needn’t wait for a response. If a response is generated, you receive notification from the system once it is complete. Examples include the observer pattern, messaging queues, and voicemail systems.

Some people use the terms response time and latency interchangeably when talking about software performance. It is important to distinguish the difference.

Latency is the delay incurred in communicating a message (the time the message spends “on the wire”). The word latent means inactive or dormant, so the processing of a user action is latent while it is traveling across a network.

Changes in latency are typically unavoidable through changes to your code. Latency is a resource issue, which is affected by hardware adequacy and utilization.

Example: The latency in a phone call is the amount of time it takes from when you ask a question until the time that the other party hears your question. If you’ve ever talked to somebody on a cell phone while standing in the same room, you’ve probably experienced latency first hand, because you can see their lips moving, but what you hear in the phone is delayed because of the latency.

Response time is the total time it takes from when a user makes a request until they receive a response.

Response time can be affected by changes to the processing time of your system and by changes in latency, which occur due to changes in hardware resources or utilization.

Example: The response time in phone conversation is the amount of time it takes for you to ask a question and get a response back from the person that you’re talking to.

Processing time is the amount of time a system takes to process a given request, not including the time it takes the message to get from the user to the system or the time it takes to get from the system back to the user.

Processing time can be affected by changes to your code, changes to systems that your code depends on (e.g. databases), or improvements in hardware.

Example: The processing time in a phone conversation is the amount of time the person you ask a question takes to ponder the question and speak the answer (after he hears the question of course).

In these terms:
Latency + Processing Time = Response Time

In many cases, you can assert that your latency is nominal, thus making your response time and your processing time pretty much the same. I guess it doesn’t matter what you call things as long as everybody involved in your performance analysis understands these different aspects of the system. For example, it is useful to make a graph latency vs. response time, and it is important for all the parties involved to know the difference between the two.

UPDATE: Some people have pointed me to books that support the definitions I’ve made. See:

- Concurrent Programming In Java by Doug Lea (chapter 1.3.3)
- Patterns of Enterprise Application Architecture by Martin Fowler (Introduction)

Both Lea and Fowler’s definition of latency corroborate mine. Fowlers definitions are pretty much the same as what I’ve layed out here. Fowler additionally defines responsiveness as the amount of time it takes to hear back something (anything). He points out that this may be the most important performance measurement from a user’s perspective. The only difference is that Lea’s definition of response time is the same as Fowler’s definition of responsiveness. I tend to like Fowler’s definition better.

Also, if you do a search for latency (try googling: “define:latency”) most of the definitions you get will agree with mine: latency is the amount of time a request spends “on the wire”.