On the .NET platform, the exception raised reads “System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted <host>:<port>“. 

In Java, the exception is “java.net.BindException: Address already in use: connect“. 

Both exceptions are misleading because they are generally associated with server socket conflicts – not outbound client socket connections.  However, a better understanding of the TCP state machine sheds some light on this behavior – and a solution.

Common Port Conflict Exceptions

Whenever TCP/IP encounters a port conflict, you can expect one of the two following exceptions to be thrown depending upon your environment:

In a C# environment, you’ll see this exception:

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted <host>:<port>

In Java, you’ll see this:

java.net.BindException: Address already in use: connect

at java.net.PlainSocketImpl.socketConnect(Native Method)

at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)

at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)

at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)

at java.net.Socket.connect(Socket.java:519)

at java.net.Socket.connect(Socket.java:469)

If you see these exceptions thrown when a server socket attempts to listen for incoming connections, the cause is obvious: the port you’re attempting to listen on is already in use.  For example, if you bring up a Web server, but another Web server is already running, an exception will be thrown because port 80 (or 8080) is already listening on behalf of another thread or application.

These exceptions are often confusing, however, when thrown setting up a client connection.  Client TCP connections are always assigned an OS-selected port on the local side, so why is the operating system selecting an active port?  The truth is the exception indicates no local port numbers are available to the client.  This misreporting of the error by the OS is half the confusion.

Tuning Local Client Port Range

The problem is two-fold.  First, Linux and Windows make only a certain number of ports available to client sockets – the default is in the range of 1024 to 5000.  Hence, you may have only 3,976 active client connections at a time.  For most systems, this is plenty.  However, in specific circumstances on systems requiring a large number of outbound connections, this limit can be exhausted.

This range, however, can be tuned.  On Windows,  the upper bound for client port assignments can be adjusted using the MaxUserPort DWORD value on this registry key:

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

Of course, rather than using the cumbersome regedit, you can download IPTuner for free to quickly optimize your Windows IP stack

On Linux, both the lower and upper bounds can be set using the following parameter:

net.ipv4.ip_local_port_range = 32768 65536

How this parameter is set in Linux varies depending upon the flavor and version of Linux you’re using – and you’ll need to restart networking after you change it.

Tuning TCP TIME_WAIT Timeout Value

The second cause of these exceptions has to do with the TCP state model and the way sockets are closed.  Even after a socket has officially been “closed”, it hangs around in a TIME_WAIT state as a safety mechanism to deal with stray packets.  The default wait time on all operating systems, generally, is ridiculously long (240 seconds on Windows).  So, even if an application doesn’t require a lot of concurrent connections, it can still run out of available ports in a high load situation.  If even one connection is repeatedly opened and closed fast enough, you’ll soon have all available local sockets hanging around in a TIME_WAIT state and none available for new clients.

The TIME_WAIT state duration, however, is also tunable.

On Windows, using the same registry key, the TCPTimedWaitDelay value can be used to adjust the TIME_WAIT duration from 30 to 300 seconds.  Of course, rather than using the cumbersome regedit, you can download IPTuner for free to quickly optimize your Windows IP stack.

On Linux, the wait delay is configured using the following parameter:

net.ipv4.tcp_fin_timeout = 30

By decreasing the TCP wait delay, closed sockets spend less time in the TIME_WAIT state and get returned to the pool of available client ports faster. However, to avoid communication problems, do not lower this value below 30 seconds.

Administrator Privileges Required

On both Linux and Windows (even if using IP tuner or regedit), you’ll require administrator privileges to change these parameters.  However, anyone can view these settings to at least verify if they make sense.

• Download IPTuner for Windows here.

However, managing multiple threads and cross-thread communication adds complexity to your code.  Fortunately, the .NET Framework has a useful design pattern applied to its I/O classes which easily enables asynchronous calls.  Let’s take a look at an example.

Async I/O for a DNS lookup 

Suppose you need to lookup the IP address of a host.  The simplest way to do this is to use the System.Net.Dns class:

IPAddress[] hostAddresses = Dns.GetHostAddresses(“www.gavaghan.org”);

A DNS lookup doesn’t take terribly long and, in most cases, the synchronous example above is fine.  DNS servers are highly efficient, and local DNS servers will cache authoritative data to optimize response times.

However, suppose you’re implementing a high performance mail server that detects spam by querying multiple real time DNS blacklists.  For every incoming message, you must execute a dozen DNS operations:

IPAddress[] spamcop = Dns.GetHostAddresses(“22.154.199.213.bl.spamcop.net”);

IPAddress[] spamhaus = Dns.GetHostAddresses(“22.154.199.213.pbl.spamhaus.org”);

IPAddress[] fiveten =

Dns.GetHostAddresses(“22.154.199.213.blackholes.five-ten-sg.com”);

//

// . . . and a dozen others

//

Each synchronous lookup blocks waiting for a response before moving on to the next lookup.  The cumulative effect of these delays will get costly.  Ideally, you’d want to perform each lookup on its own thread and let the requests run concurrently.

So, let’s implement a method that looks like this:

public class AsyncDNSExample

{

public List<IPAddress> MultiHostLookup(List<string> hosts)

{

This method will accept a list of host names, execute concurrent DNS lookups for all of them, and return with a list of resolved addresses.  Here’s how we might use this method:

class Program

{

static void Main()

{

// build list of hosts to lookup

List<string> hosts = new List<string>();

hosts.Add(“www.gavaghan.org”);

hosts.Add(“www.itko.com”);

hosts.Add(“sombrita.com”);

// perform the concurrent lookup

AsyncDNSExample lookup = new AsyncDNSExample();

List<IPAddress> addressList = lookup.MultiHostLookup(hosts);

// write out the results

foreach (IPAddress address in addressList)

{

Console.WriteLine(address);

}

}

}

Begin and End methods

Many of .NET’s I/O classes have asynchronous versions of their synchronous methods.  For example, the Read() and Write() methods on System.IO.Stream have respective BeginRead() and BeginWrite() counterparts.  System.Net.Sockets.Socket has BeginAccept() and BeginConnect().  And, in benefit of this example, Dns has BeginGetHostAddresses().

All of the Begin* methods cause the object’s work to execute on a worker thread in the .NET thread pool.  These methods take the same parameters as their synchronous counterparts plus two additional parameters supporting the async framework.

For example, here’s the signature for BeginGetHostAddresses():

public static IAsyncResult BeginGetHostAddresses(

string hostNameOrAddress,

AsyncCallback requestCallback,

Object state

)

One added parameter is an AsyncCallback delegate.  The delegate identifies the callback method .NET will invoke once asynchronous processing has completed.  The callback method takes a single parameter of type IAsyncResult.  The IAsyncResult object must be used to access the result of the asynchronous call.

The second added parameter is an arbitrary state object (possibly null) that may be used to coordinate between the caller and the callback.  The state object is made available to the callback method through the IAsyncResult parameter.  An example is included a little later.

For each Begin* call, a corresponding End* call must be invoked to get the results of the method.  End* methods block synchronously until processing has been completed.  However, when called from within the callback method, End* methods return immediately because, at that point, the work is known to be done.

Let’s take a look at how our MultiHostLookup() method can be implemented using the asynchronous version of GetHostAddresses():

public class AsyncDNSExample

{

public List<IPAddress> MultiHostLookup(List<string> hosts)

{

// we’ll fill this list with the result of the DNS lookups

List<IPAddress> addressList = new List<IPAddress>();

foreach (string host in hosts)

{

// begin an asynchronous lookup for each host

Dns.BeginGetHostAddresses(

host,

GetHostAddressesCallback,

addressList

);

}

//

// we can do additional work here while the

// DNS lookups continue in parallel

//

lock (addressList)

{

// ensure all lookups have returned, otherwise wait

while (addressList.Count != hosts.Count)

{

Monitor.Wait(addressList);

}

}

return addressList;

}

}

This method begins by allocating the List<IPAddress> object we’ll use to return our resolved addresses.  Then, we loop over each of the host names in the hosts List<string> and call BeginGetHostAddresses().  Once this loop completes, all of the DNS queries are executing in parallel.

Notice the first parameter to BeginGetHostAddresses() is a host name – just like its synchronous counterpart.  For the second parameter, we pass a reference to our callback method, GetHostAddressesCallback(), which is defined below.  The third parameter is our result List<IPAddress>.  This will make the List available to the callback method.  When each DNS query completes, the callback method can update the list with each resolved address.

At this point, if we wanted to, we could code other logic to execute as we wait for the queries to complete.

Finally, we check the length of the list of resolved IP addresses to see if it’s the same length as the list of host names.  To do this, we must first lock the address list object (after all, we don’t want our address list modified on a callback thread at the same time we’re trying to inspect it).  If the list sizes are equal, we know all lookups have completed and we can return from the method.  Otherwise, we release the lock on the address list and block until receiving notification from the callback thread.

It’s all pretty simple.  Now, let’s see how to implement the callback method:

public class AsyncDNSExample

{

private void GetHostAddressesCallback(IAsyncResult result)

{

// This method may fail with a SocketException, particularly

// if the host is not found. A more robust solution would

// handle such cases.

IPAddress[] addresses = Dns.EndGetHostAddresses(result);

// for simplicity, we’ll take the first address

IPAddress address = addresses[0];

// the address list we passed in is accessbile from AsyncState

List<IPAddress> addressList = (List<IPAddress>)result.AsyncState;

// we need to ensure updates to the address list are threadsafe

lock (addressList)

{

addressList.Add(address);

// notify listeners that another address has been added

Monitor.PulseAll(addressList);

}

}

// this is our public method for performing multiple, concurrent

// DNS requests

public List<IPAddress> MultiHostLookup(List<string> hosts)

{

. . . .

}

}

The first thing that happens is the call to EndGetHostAddresses() with the IAsyncResult object passed in.  This call returns immediately with the result of the DNS query (it returns an array of IP addresses but, for simplicity, we’ll assume the first one is all we need).

Next, we get a reference to the List<IPAddress> object passed in by the Begin* call. This is where we’re going to save our resolved IP addresses.  However, for thread safety, we can only add our result from within a lock block.  We don’t want to be manipulating the list at the same time as another callback!

Finally, we pulse all threads listening on the result object.  This schedules the thread executing MultiHostLookup() to check if all of the results have been received.

Conclusion

Using asynchronous I/O can make your applications faster and your user interfaces more responsive – particularly when executing long running tasks and tasks that would otherwise leave the CPU idle. However, even with the .NET design pattern, multithreaded programming always adds to code complexity. So, only leverage this framework where performance optimization is required.

Developing software that uses SSL is an entirely different matter.  The simplicity quickly fades, and the developer must confront the complexities of certificate management, trust stores, handshaking, and a host of other details that must be perfectly aligned to make the secure communication work.  In Part 1, we’ll cover a very high level of SSL concepts.  In subsequent posts, we’ll take a deeper dive into making these connections happen in both Java and C#.

Understanding SSL

SSL uses public key/private key cryptography for three purposes. The most fundamental use is to encrypt data communication between the server and client.  However, it is also used to allow the server to prove its identity to the client and prevent man-in-the-middle attacks (where a malicious intermediary intercepts messages from the client and masquerades as the intended server).

A third use is for allowing the client to prove its identity to the server.  Mutual authentication is an important and powerful feature of SSL, and it’s probably underused.  For now, we’ll just focus on the semantics of server authentication.  If you understand server authentication, you’ll be well on your way to understanding client authentication on your own.

About Certificates

Three fundamental components are involved in setting up an SSL connection between a server and client: a certificate, a public key, and a private key.

Digital certificates are used to identify an entity.  The entity could be a person (when used for secure email), or it could be a computer (when used for SSL).  There is quite a bit of information stored in a digital certificate, but the most important part is the name of the entity it is identifying.

The identity, also known as the “subject”, is specified as an X.509 distinguished name.  A distinguished name contains multiple components.  For example, the distinguished name on the certificate used to setup an HTTPS connection for Amazon.com’s shopping cart check-out looks like this:

CN=www.amazon.com,

O=Amazon.com Inc.,

L=Seattle,

S=Washington,

C=US

How do we find this information?  From Internet Explorer, browse to any secure web page (one with an https:// protocol in the URL).  Right-click on the page and select “Properties”.  From the properties page, click the “Certificates” button.  On the “Details” tab, we can see all of the information embedded in the certificate.  By selecting the “Subject” entry, we can see the entity the certificate identifies:

For the purposes of establishing an SSL connection to a server, the only interesting part of the distinguished name is the “Common Name” specified by the “CN” component.  This is the name the server uses to identify the domain name of the host.

To establish a secure connection to Amazon.com, a client first resolves the domain name www.amazon.com.  After the SSL connection has been initiated, one of the first things the server will do is send its digital certificate.  The client will perform a number of validation steps before determining if it will continue with the connection.

Most importantly, the client will compare the domain name of the server it intended to connect to (in this case, www.amazon.com) with the common name (the “CN” field) found in the subject’s identity on the certificate.  If these names do not match, it means the client does not trust the identity of the server (and the client will likely choose to terminate the connection).

Although the server name may be correct, the client must still verify the integrity of the certificate to determine if it has been forged or tampered with.  The client does this by verifying the digital signature on the certificate.  We’ll talk more about digital signatures in a moment.

The client will also ensure the certificate is being used within a valid time frame.  All certificates contain an “issue date” and an “expiration date”.  A certificate is considered invalid outside of that date range.

Public and Private Keys

Public keys and private keys are number pairs with a special relationship.  Any data encrypted with one key can be decrypted with the other.  This is known as asymmetric encryption.  The security of asymmetric encryption lies in the difficulty of cracking encrypted data even when the key used for encryption is known.

The server’s public key is embedded within its certificate.  The public key is freely distributed so anyone wishing to establish an encrypted channel with the server may encrypt their data using the server’s public key.  The server will decrypt this message using its private key.  For this reason, private keys are closely guarded and kept secure.

Digital Signatures

Just as data may be encrypted with a public key and decrypted with a private key, the reverse is also true.  Data encrypted with a private key may be decrypted with the corresponding public key.

This property of keys is used to ensure the integrity of a digital certificate in a process called digital signing.

A hashing algorithm (such as SHA1 or MD5) is a means of processing all of the bytes of a message and producing a numeric “hash value”.  Hash values have long been used to ensure the integrity of messages that may become corrupted during transport.  A sender will transmit a message followed by the hash value it calculated for the message it intends to send.  The receiver calculates the hash value for the message it receives.  If the receiver calculates a different hash value than the one that was sent, the receiver concludes the message was corrupted during transit (and generally asks the sender to resend).

A hashing algorithm may also be used to determine if a message has been forged or tampered with.  Complicating this, however, is that a malicious third party could intercept a message, modify it, and simply recalculate the hash.  Asymmetric encryption technology solves this.

If a message sender wants to convince a recipient that his message is authentic and has not been tampered with, he will do two things.  First, the sender will calculate a hash value for the message.  This hash value will then be encrypted using the sender’s private key (a key which the sender, and only the sender, knows).  When the client receives the message, the client decrypts the hash value using the sender’s public key.  If the message has been tampered with, or if the message has been signed with anything other than the sender’s private key, the hash values will not agree and the client will not consider the message authentic.

Certificate Signing

When a certificate is created, it is digitally signed.  The digital signature is used to verify the authenticity of the certificate.  In an SSL connection, the client will attempt to verify the signature on the certificate presented by the server before deciding to continue establishing the connection.

Self-signed certificates

The simplest certificate is a self-signed certificate.  The signature on a self-signed certificate is calculated using the same private key associated with the public key found on the certificate.  In a software development environment, self-signed certificates are an easy way to build testing environments that establish SSL connections without having to deal with the time and expense of obtaining a certificate through an establish certificate authority.

Certificate Authority signed certificates

Certificates may also be signed by a certificate authority (CA).  A CA is a trusted third party that digitally signs certificates for entities that have gone through an established vetting process.  The CA, itself, also has a certificate that can be analyzed for authenticity – and the CA’s certificate might also be signed by yet another trusted third party (in this case, the CA is known as an intermediate CA).  All of these certificates, together, form a certificate chain.  At the top of the chain is a certificate authority called a Root CA that uses a self-signed certificate.

Returning to the Amazon.com example, we can examine the server certificate and see that it is not a self signed certificate – it is signed by a CA with a distinguished named of:

CN=VeriSign Class 3 Secure Server CA – G2,

OU=Terms of use at https://www.verisign.com/rpa (c)09,

OU=VeriSign Trust Network,

O=VeriSign, Inc.,

C=US

From the certificate details tab we looked at earlier, we can find the name of the certificate issuer by selecting the “Issuer” entry:

VeriSign is a trusted third party that issues certificates for, among other things, eCommerce applications.

Why is it important to have a certificate signed by a trusted third party?  It’s important because new HTTPS-based Web applications are being deployed all of the time.  In terms of browser-based, retail eCommerce applications, it’s simply impractical for users to manage a list of all of the server certificates they have decided to “trust”.  Furthermore, reliably and securely obtaining a web site’s real server certificate would be too problematic.

Consider a new Amazon.com customer.  When the shopping cart checkout sends Amazon.com’s certificate identifying itself as www.amazon.com, how does the customer know to trust the certificate?  Although the certificate may have a valid name and signature on it, how does the customer decide to trust the certificate?  If it is self-signed, it could have been signed by anyone – including a malicious man-in-the-middle.  What the customer needs is a reliable means of receiving Amazon’s certificate that is protected from forgery.

To do this, Amazon chose not to use a self-signed certificate.  Instead, for a fee, it requested that VeriSign sign its online shopping certificate.  When the customer receives Amazon.com’s certificate, she says “I trust that I have a legitimate copy of VeriSign’s CA certificate, I trust VeriSign to only sign certificates of the real domain name owners, and I can see that Amazon.com’s certificate is signed by VeriSign.  Therefore, I believe the server responding at www.amazon.com is truly owned and managed by the same entity owning the www.amazon.com domain name.”

Where Do Trusted CA’s Come From?

Why does the customer believe she has a legitimate copy of VeriSign’s CA certificate?  She believes this because a set of “trusted” CAs came pre-installed with her Web browser software.  Internet Explorer, Firefox, and all other leading browser vendors pre-configure their browsers to trust well known CAs such as VeriSign, Thawte, and Network Solutions.

C# programs will generally access the Windows Cryptographic Service Provider for trusted certificates.  The CSP is a shared OS resource usable by any program, and is also the same trust store consulted by Internet Explorer.

Similarly, the Java Runtime Environment comes with a pre-configure set of trusted certificate authorities.  The collection of trusted certificates can be found at [JRE_HOME]/lib/security/cacerts.  The keytool, a command line utility found in the SDK, can be used to inspect and manipulate this file.  The default password for the cacerts keystore is “changeit”.

Summary

Public key cryptography is at the heart of SSL.  While most developers are aware this technology is used to encrypt a data channel, most are unfamiliar with its use of digital signing for identity authentication and message validation.  It is the lack of understanding of these other uses that generally stymie their efforts to implement SSL.

Stayed tuned for more posts on the lower level details of implementing SSL technology,

The C# and Java 4-byte float data type provides 7 significant digits of precision, while the 8-byte double type provides 15. Using the higher precision double data type helps minimize the roundoff error, but it must still be addressed.

So, when I encountered the C# 12-byte decimal data type with its 28 significant digits, and Java’s arbitrary size BigDecimal data type, I figured these were simply ways of further minimizing the problem with a wider floating point type. Only after digging deeper did I realize that the implementation behind both of these data types is a stroke of genius.

The need for precision

In scientific applications, inexact representation is a non-issue. Whether you’re measuring the temperature on the Sun or the diameter of an atom, things like numeric magnitude matter more than accuracy out to the 17th decimal point. In graphical applications, you’re probably rounding off to the nearest pixel, anyway. In general, computers provide floating point precision that greatly exceeds any practical need.

You get into trouble, however, with financial applications. Even when you’re dealing with million dollar transactions, your debits and credits must match exactly. Off by a penny? You’ll drive the accountants nuts!

Consider this C# example. Below, pretend we’ve got a bank account with $100,000 and we withdraw $99,999.67. How much money is left? $0.33, right? Let’s see what C# calculates:

using System;

namespace FloatingPoint

{

public class SubtractionRoundoff

{

static void Main()

{

float floatValue = 100000;

double doubleValue = 100000f;

decimal decimalValue = 100000m;

floatValue -= 99999.67f;

doubleValue -= 99999.67;

decimalValue -= 99999.67m;

Console.WriteLine(“float result = ” + floatValue);

Console.WriteLine(“double result = ” + doubleValue);

Console.WriteLine(“decimal result = ” + decimalValue);

}

}

}

If you’ve ever written floating point code, you can probably predict the first two lines:

float result = 0.328125
double result = 0.330000000001746
decimal result = 0.33

Both the float and double calculations have roundoff error, even though both perform calculations within the limits of their significant digits. The integer value 100,000 can be represented precisely, but neither float nor double can precisely represent the fractional part of 99,999.67. “.67″ would require an infinitely repeating series of bytes. C# and Java must truncate the bytes to the width of the data-type. This representational error then appears after the subtraction operation.

But, how come the decimal type nailed it – exactly? Shouldn’t the decimal type still have some error, albeit with far less magnitude than the double? Java BigDecimal will hit it on the nose, too. The reason for this is a thing of beauty.

How floating point numbers are represented

The gory details of floating point representation is a bit much to cover here, especially when it has already seen a great discussion in Bill Venner’s article Floating-point Arithmetic. Although the article is Java-specific, the basic details are completely valid for C#. It’s a must read if words like “mantissa” and “radix” are unfamiliar to you.

Floating point numbers are essentially represented as a fixed length integer (the “mantissa”) combined with a scale that shifts the decimal point left or right (can we still call it a “decimal” point when we’re dealing in base 2?) This shifting is determined by a radix (the “base” of the representation) raised to an exponent.

float and decimal both use a radix of 2. Hence, the number 3.125 could be represented with an integral mantissa of 25 and an exponent of -3:

25 * 2^-3 = 3.125

Okay, remember this tidbit from high school? How can you tell if the decimal representation of a fraction will produce a repeating decimal? If the denominator has any factors other than 2 or 5, the decimal representation will repeat infinitely. So, fractions like 1/2, 2/5, and 3/10 may be represented exactly as 0.5, 0.4, and 0.3. But, 1/3 is a infinite series of 3s (0.33333 . . .).

When representing fractions in binary, the representation of a fraction repeats infinitely if the denominator has factors other than only 2. So, 1/2 and 3/4 are fine, but not 1/10 (the number 10 includes 5 as a factor). So, the non-repeating decimal 0.1 cannot be represented precisely in a computer.

In a typical application, we enter numbers in human usable form – base 10. But, the computer makes an inexact conversion to base 2, performs some arithmetic on the inexact numbers, and then converts the result back to base 10. No wonder roundoff problems occur!

How decimal and BigDecimal are different

Don’t fall asleep on me now, I’m working up to the grand finale!

Floating point numbers have traditionally been represented in base 2 because that’s a natural representation for computers. The arithmetic is fast and efficient.

The genius in decimal and BigDecimal is they both use base 10 internally for both storage and arithmetic. When you enter 0.1 in an application, you get precisely 0.1. These new floating point types understand numbers the same way you do, so there’s no inexact internal representation. You can add and subtract financial values all day and not lose a thing. No need to round off string values to the nearest penny.

What about performance? The answer here is predictable: base 10 arithmetic is slow – very slow. It has to be done in software, whereas base 2 floating point arithmetic can be offloaded to a specialized floating point processor. For hard performance comparison numbers, check out Wesner Moise’s Decimal Performance. But, for most financial apps, the performance hit is a non-issue – especially when compared against the cost of programmer’s trying to correct roundoff errors manually.

Some calculations will still result in repeating decimals. Calculating 1/3 will still result in a repeating decimal. But, these issues have always needed a business solution. On interest calculations, banks have always had to address whether fractional pennies in interest calculations round to the benefit of the bank or the depositor. Those problems are easily handled, but esoteric problems introduced in the black magic of the CPU aren’t. Using decimal and BigDecimal for financial calculations allows programmers to worry only about the easy problems.

Be warned, however, that the NHibernate DLLs require a high level of trust in the ASP.NET environment they’re deployed to. I spent an entire weekend beating my head against a wall trying to get a simple app up on my GoDaddy account. I suspect NHibernate probably wasn’t designed with a medium trust environment in mind. I was able to make a few tweaks to get the code running with fewer permissions requirements. However, the permissions required to enable dynamic proxies – a fundamental part of the NHibernate architecture – are non-negotiable.

I learned from GoDaddy tech support that their Deluxe Windows plan, a shared host environment, simply doesn’t allow those permissions. I’d need to upgrade to a dedicated server, and that’s just a little too pricey for an environment simply for experimentation. I was able to get NHibernate working without any hacks at Webhost4life, but I thought I’d share what I tried first at GoDaddy just to help you understand the permissions implications if you’re in a medium trust environment — and how you might need to address them on your own projects.

Step 1 – Allow Partially Trusted Callers

Right off the bat, ASP.NET was complaining that my domain object assembly didn’t allow partially trusted callers:

[SecurityException: That assembly does not allow partially trusted callers.]

This is because NHibernate, during its startup configuration, references the persistent classes it’s configured to manage. The callbacks were denied because partially trusted callers are not permitted unless explicitly enabled. So, I needed to enable partially trusted callers in my own domain object DLL by adding this attribute to the assembly:

[assembly: AllowPartiallyTrustedCallers()]

Step 2 – Tweak NHibernate.Mapping.Attributes

I use NHibernate.Mapping.Attributes to map my domain objects to my database tables. It’s a lot cleaner and easier to maintain than the old fashioned XML configuration files. Unfortunately, this add-on library to NHibernate doesn’t explicitly allow partially trusted callers. So, we again run into the problem of security exceptions when other assemblies attempt to invoke the NHibernate.Mapping.Attributes library.

Fortunately, the NHibernate library comes with a source code download (isn’t open source software great?). I simply added the AllowPartiallyTrustedCallers attribute to the NHibernate.Mapping.Attributes assembly and rebuilt the DLL using the solution and projects provided. Voila!

The next roadblock, however, was this exception coming out of NHibernate.Mapping.Attributes:

SecurityException: Request for the permission of type ‘System.Security.Permissions.FileIOPermission

This simply turns out to be a quirk in how the HbwWriter class was implemented. The class attempts to construct a “Type Name” + “Assembly name” string like this:

string typeName = type.FullName + “, ” + type.Assembly.GetName().Name;

The problem here is that the Assmbly.GetName() method requires FileIOPermission in order to return the assembly path. It’s not necessary for HbmWriter to get the assembly name in this fashion, so I refactored this code to build the string in a way that doesn’t require FileIOPermission:

string assemblyName = type.Assembly.FullName;

int comma = assemblyName.IndexOf(“,”);

assemblyName = assemblyName.Substring(0, comma);

string typeName = type.FullName + “, ” + assemblyName;

Step 3 – Get Stymied By DynamicMethod

I solved the problem of partially trusted callers and an unnecessary dependence on FileIOPermission, but the next problem I encountered was a showstopper.

In the core NHibernate library, the ReflectionOptimizer class attempts to instantiate DynamicMethod instances to hang persistence-enabled methods off of your domain objects:

new DynamicMethod(string.Empty, returnType, argumentTypes, owner, canSkipChecks);

After decompiling the .NET SDK, I discovered this unavoidable permission demand in the DynamicMethod constructor:

new ReflectionPermission(ReflectionPermissionFlag.ReflectionEmit).Demand();

If ReflectionEmit is denied, this line of code throws a security exception. Alas, it’s not permitted in the GoDaddy environment I was using. It’s also nothing that can be reasonably worked around because dynamic proxies are an integral part of how NHibernate is built.

Everything works fine when I deploy to my new Webhost4life account because the shared environment permissions are more lax. So, the lesson learned is to scrutinize the trust level of your target platform before making an investment in NHibernate.

It’s unfortunate that most ASP.NET hosting providers aren’t explicit about the trust levels they provide in their different environments. I also discovered that their level one support techs generally can’t provide that information, either. Your best bet is to rely on the experience of others and to share your own.

Several years ago, I stumbled on a great pastime called “geocaching.” It’s a worldwide treasure hunting game where participants use handheld GPS receivers to find hidden “caches” – small boxes filled with prizes, trinkets, and “travel bugs“. The caches are hidden by other participants who post nothing more than the latitude and longitude on a website like Geocaching.com. My children and I have had a blast. It’s a great way for a grown man to justify playing in the woods (and buying an expensive gadget!) under the pretense of “playing with the kids.” With over 420,000 caches in 222 countries on all continents (including Antarctica!) there are bound to be several near you.

Want to know more? Check out this video of my son on a geocache hunt.

So, being the true geek I am, I coded up a bunch of applications to record where we’ve been, where we’d like to go, and interesting waypoints along the way. Often, I’d ask the question “How far is it for here to there?”

The Geodetic Inverse Problem

“How far?” turns out to be a fairly complicated question. For centuries, humankind has known Earth is round – but everything else about the shape of Earth is less understood. In fact, an entire field called “geodesy“, or “geodetics,” focuses on understanding the shape of Earth.

If we assume Earth is a perfect sphere, the math is easy. Given the size of Earth and the latitude and longitude of two points, we can quickly calculate the “great circle” distance and direction from one point to the next.

But, Earth is not a perfect sphere. It’s an irregular shape geodesists call the “geoid”. Because precise measurements of the geoid and the corresponding distance calculations would be impractical, the geoid is often modeled as an ellipsoid – an object resembling a sphere but slightly flattened at the poles. It’s still an inexact model, but it performs far better than the spherical model.

That’s where the math gets hard. The Geodetic Inverse Problem – finding the distance and direction from one point to another along an ellipsoid – does not have a closed form solution. However, in 1975, Thaddeus Vincenty developed an extremely accurate iterative solution for which he won the Department of Commerce Medal for Meritorious Service. If you want to sprain your brain, you can read the full publication of his solution.

Or, you can just download my C# implementation of Vincenty’s Formula.

Building the code

I’ll start with a convenient type for encapsulating angles. We’ll need this for latitudes and longitudes. It might seem to be overkill since we could simply uses double instead of a custom Angle type, but humans think in “degrees” while computers do math in “radians”. Rather than risk confusion and sprinkle conversion code throughout, I thought this would be easier:

namespace Gavaghan.Geodesy

{

public struct Angle : IComparable<Angle>

{

private const double PiOver180 = Math.PI / 180.0;

private double mDegrees;

static public readonly Angle Zero = new Angle(0);

static public readonly Angle Angle180 = new Angle(180);

public Angle(double degrees)

{

mDegrees = degrees;

}

public double Degrees

{

get { return mDegrees; }

set { mDegrees = value; }

}

public double Radians

{

get { return mDegrees * PiOver180; }

set { mDegrees = value / PiOver180; }

}

//

// Equals, IComparable<T> implementation and

// comparison operators omitted for clarity.

// See full source code download

//

}

}

Some critical portions of the Angle type above are omitted for clarity – like all of the comparison operators. You can check out the complete implementation in the source code download.

Next, we have a class that encapsulates a location on an ellipsoid.

namespace Gavaghan.Geodesy

{

public struct GlobalCoordinates : IComparable<GlobalCoordinates>

{

private Angle mLatitude;

private Angle mLongitude;

public GlobalCoordinates(Angle latitude, Angle longitude)

{

mLatitude = latitude;

mLongitude = longitude;

}

public Angle Latitude

{

get { return mLatitude; }

set { mLatitude = value; }

}

public Angle Longitude

{

get { return mLongitude; }

set { mLongitude = value; }

}

}

}

Negative latitudes are in the southern hemisphere, and negative longitudes are in the western hemisphere. Once again, the IComparable<T> implementation is omitted for clarity.

Now, we start getting to the fun part. The next type encapsulates the “geodetic curve.”

namespace Gavaghan.Geodesy

{

public struct GeodeticCurve

{

private readonly double mEllipsoidalDistance;

private readonly Angle mAzimuth;

private readonly Angle mReverseAzimuth;

public GeodeticCurve(double ellipsoidalDistance,

Angle azimuth, Angle reverseAzimuth)

{

mEllipsoidalDistance = ellipsoidalDistance;

mAzimuth = azimuth;

mReverseAzimuth = reverseAzimuth;

}

public double EllipsoidalDistance

{

get { return mEllipsoidalDistance; }

}

public Angle Azimuth

{

get { return mAzimuth; }

}

public Angle ReverseAzimuth

{

get { return mReverseAzimuth; }

}

}

}

A “geodetic curve” is the solution we’re looking for. It describes how to get from one point on an ellipsoid to another. The ellipsoidal distance is the distance, in meters, between the two points along the surface of the ellipsoid. The azimuth is the direction of travel from the starting point to the ending point. The reverse azimuth, of course, is the direction back from the endpoint (which isn’t necessarily a 180 degree turn on an ellipsoid).

The final input we need to Vincenty’s Formula is an ellipsoid. We hold onto four parameters of an ellipsoid: the length of each semi-axis (in meters), the flattening ratio, and the inverse of the flattening ratio. Technically, we only need the length of one semi-axis and any one of the other three parameters. We’ll record all four for convenience.

namespace Gavaghan.Geodesy

{

public struct Ellipsoid

{

private readonly double mSemiMajorAxis;

private readonly double mSemiMinorAxis;

private readonly double mFlattening;

private readonly double mInverseFlattening;

private Ellipsoid(double semiMajor, double semiMinor,

double flattening, double inverseFlattening)

{

mSemiMajorAxis = semiMajor;

mSemiMinorAxis = semiMinor;

mFlattening = flattening;

mInverseFlattening = inverseFlattening;

}

static public readonly Ellipsoid WGS84

= FromAAndInverseF(6378137.0, 298.257223563);

static public readonly Ellipsoid GRS80

= FromAAndInverseF(6378137.0, 298.257222101);

static public readonly Ellipsoid GRS67

= FromAAndInverseF(6378160.0, 298.25);

static public readonly Ellipsoid ANS

= FromAAndInverseF(6378160.0, 298.25);

static public readonly Ellipsoid Clarke1880

= FromAAndInverseF(6378249.145, 293.465);

static public Ellipsoid FromAAndInverseF(double semiMajor,

double inverseFlattening)

{

double f = 1.0 / inverseFlattening;

double b = (1.0 – f) * semiMajor;

return new Ellipsoid(semiMajor, b, f, inverseFlattening);

}

public double SemiMajorAxis

{

get { return mSemiMajorAxis; }

}

public double SemiMinorAxis

{

get { return mSemiMinorAxis; }

}

public double Flattening

{

get { return mFlattening; }

}

public double InverseFlattening

{

get { return mInverseFlattening; }

}

}

}

Generally, you won’t need to specify ellipsoid parameters. The Ellipsoid type has a number of static instances that define “reference ellipsoids”. Reference ellipsoids represent some organization’s consensus on the “best” ellipsoidal parameters to use to model Earth. Two of the most widely accepted reference ellipsoids are defined above: WGS84 (the 1984 World Geodetic System) and GRS80 (the 1980 Geodetic Reference System).

Finally, we have the class that actually implements Vincenty’s Formula to solve the Geodetic Inverse Problem given a reference ellipsoid and two sets of global coordinates (equation numbers in comments relate directly to Vincenty’s publication):

using System;

namespace Gavaghan.Geodesy

{

public class GeodeticCalculator

{

private const double TwoPi = 2.0 * Math.PI;

public GeodeticCurve CalculateGeodeticCurve(Ellipsoid ellipsoid,

GlobalCoordinates start, GlobalCoordinates end)

{

// get constants

double a = ellipsoid.SemiMajorAxis;

double b = ellipsoid.SemiMinorAxis;

double f = ellipsoid.Flattening;

// get parameters as radians

double phi1 = start.Latitude.Radians;

double lambda1 = start.Longitude.Radians;

double phi2 = end.Latitude.Radians;

double lambda2 = end.Longitude.Radians;

// calculations

double a2 = a * a;

double b2 = b * b;

double a2b2b2 = (a2 – b2) / b2;

double omega = lambda2 – lambda1;

double tanphi1 = Math.Tan(phi1);

double tanU1 = (1.0 – f) * tanphi1;

double U1 = Math.Atan(tanU1);

double sinU1 = Math.Sin(U1);

double cosU1 = Math.Cos(U1);

double tanphi2 = Math.Tan(phi2);

double tanU2 = (1.0 – f) * tanphi2;

double U2 = Math.Atan(tanU2);

double sinU2 = Math.Sin(U2);

double cosU2 = Math.Cos(U2);

double sinU1sinU2 = sinU1 * sinU2;

double cosU1sinU2 = cosU1 * sinU2;

double sinU1cosU2 = sinU1 * cosU2;

double cosU1cosU2 = cosU1 * cosU2;

// eq. 13

double lambda = omega;

// intermediates we’ll need to compute ’s’

double A = 0.0;

double B = 0.0;

double sigma = 0.0;

double deltasigma = 0.0;

double lambda0;

bool converged = false;

for (int i = 0; i < 10; i++)

{

lambda0 = lambda;

double sinlambda = Math.Sin(lambda);

double coslambda = Math.Cos(lambda);

// eq. 14

double sin2sigma = (cosU2 * sinlambda * cosU2 * sinlambda)

+ (cosU1sinU2 – sinU1cosU2 * coslambda)

* (cosU1sinU2 – sinU1cosU2 * coslambda);

double sinsigma = Math.Sqrt(sin2sigma);

// eq. 15

double cossigma = sinU1sinU2 + (cosU1cosU2 * coslambda);

// eq. 16

sigma = Math.Atan2(sinsigma, cossigma);

// eq. 17 Careful! sin2sigma might be almost 0!

double sinalpha = (sin2sigma == 0) ? 0.0

: cosU1cosU2 * sinlambda / sinsigma;

double alpha = Math.Asin(sinalpha);

double cosalpha = Math.Cos(alpha);

double cos2alpha = cosalpha * cosalpha;

// eq. 18 Careful! cos2alpha might be almost 0!

double cos2sigmam = cos2alpha == 0.0 ? 0.0

: cossigma – 2 * sinU1sinU2 / cos2alpha;

double u2 = cos2alpha * a2b2b2;

double cos2sigmam2 = cos2sigmam * cos2sigmam;

// eq. 3

A = 1.0 + u2 / 16384 * (4096 + u2 * (-768 + u2 * (320 – 175 * u2)));

// eq. 4

B = u2 / 1024 * (256 + u2 * (-128 + u2 * (74 – 47 * u2)));

// eq. 6

deltasigma = B * sinsigma * (cos2sigmam + B / 4

* (cossigma * (-1 + 2 * cos2sigmam2) – B / 6 * cos2sigmam

* (-3 + 4 * sin2sigma) * (-3 + 4 * cos2sigmam2)));

// eq. 10

double C = f / 16 * cos2alpha * (4 + f * (4 – 3 * cos2alpha));

// eq. 11 (modified)

lambda = omega + (1 – C) * f * sinalpha

* (sigma + C * sinsigma * (cos2sigmam + C * cossigma * (-1 + 2 * cos2sigmam2)));

// see how much improvement we got

double change = Math.Abs((lambda – lambda0) / lambda);

if ((i > 1) && (change < 0.0000000000001))

{

converged = true;

break;

}

}

// eq. 19

double s = b * A * (sigma – deltasigma);

Angle alpha1;

Angle alpha2;

// didn’t converge? must be N/S

if (!converged)

{

if (phi1 > phi2)

{

alpha1 = Angle.Angle180;

alpha2 = Angle.Zero;

}

else if (phi1 < phi2)

{

alpha1 = Angle.Zero;

alpha2 = Angle.Angle180;

}

else

{

alpha1 = new Angle(Double.NaN);

alpha2 = new Angle(Double.NaN);

}

}

// else, it converged, so do the math

else

{

double radians;

alpha1 = new Angle();

alpha2 = new Angle();

// eq. 20

radians = Math.Atan2(cosU2 * Math.Sin(lambda),

(cosU1sinU2 – sinU1cosU2 * Math.Cos(lambda)));

if (radians < 0.0) radians += TwoPi;

alpha1.Radians = radians;

// eq. 21

radians = Math.Atan2(cosU1 * Math.Sin(lambda),

(-sinU1cosU2 + cosU1sinU2 * Math.Cos(lambda))) + Math.PI;

if (radians < 0.0) radians += TwoPi;

alpha2.Radians = radians;

}

return new GeodeticCurve(s, alpha1, alpha2);

}

}

}

There you have it! You have the tools you need to know the answer to the question “How far is it from here to there?”

Here’s an example of using the code to calculate how far it is from the Lincoln Memorial in Washington, D.C. to the Eiffel Tower in Paris:

using System;

using System.Text;

using Gavaghan.Geodesy;

namespace Gavaghan.Geodesy.Example

{

public class Example

{

static void Main()

{

// instantiate the calculator

GeodeticCalculator geoCalc = new GeodeticCalculator();

// select a reference elllipsoid

Ellipsoid reference = Ellipsoid.WGS84;

// set Lincoln Memorial coordinates

GlobalCoordinates lincolnMemorial;

lincolnMemorial = new GlobalCoordinates(

new Angle(38.88922), new Angle(-77.04978)

);

// set Eiffel Tower coordinates

GlobalCoordinates eiffelTower;

eiffelTower = new GlobalCoordinates(

new Angle(48.85889), new Angle(2.29583)

);

// calculate the geodetic curve

GeodeticCurve geoCurve = geoCalc.CalculateGeodeticCurve(

reference, lincolnMemorial, eiffelTower

);

double ellipseKilometers = geoCurve.EllipsoidalDistance / 1000.0;

Console.WriteLine(“Lincoln Memorial to Eiffel Tower using WGS84″);

Console.WriteLine(” Ellipsoidal Distance: {0:0.00} kilometers”,

ellipseKilometers

);

Console.WriteLine(” Azimuth: {0:0.00} degrees”,

geoCurve.Azimuth.Degrees

);

Console.WriteLine(” Reverse Azimuth: {0:0.00} degrees”,

geoCurve.ReverseAzimuth.Degrees

);

}

}

}

The library also supports 3-D geodetic calculations (measurements that account for the elevation above or below the reference ellipsoid). For complete source code, documentation, and examples, download the entire C# library.

Take a look at this method. It’s similar to a method I ran across that was intended to provide a generic means of performing some behavior based on the equivalence of two values:

static public void DoSomeWork(object obj1, object obj2)

{

Console.WriteLine(“obj1 = ” + obj1 + “; obj2 = ” + obj2 + “;”);

if (obj1 == obj2)

{

Console.WriteLine(“Objects are equal”);

// do some important work

}

else

{

Console.WriteLine(“Objects are NOT equal”);

// do some different important work

}

}

Note the use of operator== being applied to two parameters of type object. The idea here is we can pass objects of any type: int, string, or some complex type that implements Equals(). No matter what we pass, we want the code to branch based on the equivalence of the arguments.

Now, as a former Java developer, I never would have coded it this way. In Java, “obj1 == obj2” is always a reference comparison. It evaluates to true if, and only if, both arguments refer to precisely the same object instance. To compare objects for equivalence, Java programmers explictly test “obj1.equals(obj2)“.

In my C++ days, I learned that operator overloading is a risky endeavor that generally should be avoided. Given a flat class hierarchy, you’re probably safe. But, sometimes the operator functionality that gets invoked on a derived object cast as a base type is non-intuitive.

Like in this C# example.

Look what happens when we pass equivalent string instances to the above method.

static void Main()

{

// build the first string

string str1 = “foobar”;

// make the second string equivalent

// use concatenation to prevent compiler optimization

string str2 = String.Concat(“foo”, “bar”);

DoSomeWork(str1, str2);

}

Note how the second string is built using concatenation. This is necessary to prevent the compiler from using the same instance of the string literal on both assignments (this would invalidate our test).

With our string instances both equivalent to “foobar”, we call our test method and get:

obj1 = foobar; obj2 = foobar;
Objects are NOT equal

What’s up with that? Every C# developer knows that "foobar" == "foobar" will always evaluate to true since, unlike Java, C# is “smart” enough to invoke the Equals() method when operator== is called on two strings.

The problem lies in the fact that operator== is a static method that must be resolved at compile time, not a polymorphing method selected at runtime.

If obj1 and obj2 were explicity cast as string, the code would work as expected. The static method operator==( string str1, string str2 ) method is implemented to invoke Equals() for you. The Equals() method on type object is declared virtual, so it is a polymorphic method.

However, in our DoSomeWork() example, the parameters are cast as object. So, the static operator==( object obj1, object obj2 ) method is selected at compile time. And that implementation of the overloaded == operator only performs an object reference comparison. The Equals() method is never invoked!

A similar problem occurs if you try to pass a value type. The value types will get boxed before DoSomeWork() gets called. Hence, even “2 == 2” will evaluate to false.

The solution? Rewrite DoSomeWork() to invoke Equals():

static public void DoSomeWork(object obj1, object obj2)

{

Console.WriteLine(“obj1 = ” + obj1 + “; obj2 = ” + obj2 + “;”);

if (obj1.Equals(obj2))

{

Console.WriteLine(“Objects are equal”);

// do some important work

}

else

{

Console.WriteLine(“Objects are NOT equal”);

// do some different important work

}

}

Now, we’ll get the comparison behavior we wanted.

I’m going to end this post with the question “Yes, but what’s it good for?” You folks with the Ph. D. in C#, feel free to scroll to the bottom and post your answers. For my fellow mortals out there, let me recap what I’m talking about.

We all know how to declare events on a class, right? It goes something like this:

using System;

namespace AddRemoveDelegates

{

public class Account

{

private decimal balance;

public event EventHandler<EventArgs> Overdrawn;

public decimal Balance

{

get { return balance; }

set { balance = value;}

}

public void UpdateBalance(decimal amount)

{

balance += amount;

if (balance < 0)

{

if (Overdrawn != null) Overdrawn(this, EventArgs.Empty);

}

}

}

}

Straightforward, right? If the account balance goes below zero, we fire the Overdrawn event. We hook up listeners to the event like this:

using System;

namespace AddRemoveDelegates

{

class Example

{

public static void account_Overdrawn( object sender, EventArgs e )

{

Console.WriteLine(“Account is overdrawn”);

}

public static void Main(string[] args)

{

Account account = new Account();

// hookup the event listener

account.Overdrawn += account_Overdrawn;

account.UpdateBalance(-10);

}

}

}

For the most part, it’s as easy as that. But, have you ever wondered just what magic is going on inside that call to += ?

Take a moment to consider the Balance property on the Account class we defined above. How do we access it? Well, first we have to back it up with a private field (named balance with a lowercase “b”). Then, we define get and set implementations to control how the private field is accessed and altered. They teach that in Day 1 of a C# programming class.

event members work largely the same way, except the compiler does some work behind the scenes on your behalf. When you declare an event, the compiler gives you a hidden MulticastDelegate field that manages a collection of event listeners. The += and -= operators are implemented to add and remove the handlers from the hidden delegate.

However, you have the ability to explicitly implement your own behavior for += and -= using the keywords add and remove, respectively, just as properties use get and set.

Here’s an alternate implementation of the Account class:

using System;

namespace AddRemoveDelegates

{

public class Account

{

private decimal balance;

// we have to explicitly declare a MulticastDelegate

private EventHandler<EventArgs> onOverdrawn;

// here, we control the adding and removing of listeners

public event EventHandler<EventArgs> Overdrawn

{

add

{

onOverdrawn =

(EventHandler<EventArgs>)Delegate.Combine(onOverdrawn, value);

}

remove

{

onOverdrawn =

(EventHandler<EventArgs>)Delegate.Remove(onOverdrawn, value);

}

}

public decimal Balance

{

get { return balance; }

set { balance = value;}

}

public void UpdateBalance(decimal amount)

{

balance += amount;

if (balance < 0)

{

// we also have to invoke the delegate through the field, now

if (onOverdrawn != null) onOverdrawn(this, EventArgs.Empty);

}

}

}

}

We’ve added a private field of type EventHandler<EventArgs> called onOverdrawn. EventHandler<EventsArgs> is a subtype of System.MulticastDelegate, and this will be our collection of registered event listeners. We’ve also created add and remove implementations for the Overdrawn event. Using static methods Combine and Remove on the Delegate class, we can update the listeners in our MulticastDelegate.

We haven’t gained anything, yet. This is what C# would otherwise give us for free. But, think about the possibilities! Yes! The possibilities!

What possibilities?

Yes, but what’s it good for?

When the only tool you have is a hammer, every problem looks like a nail — and this is a really cool hammer. It’s got what I call “geek appeal”. It’s a clever trick to show other developers so they can bow at your genius. Unfortunately, I’m kind of at a loss for a legitimate use — except maybe for some contrived examples.

I don’t like creating side effects in what is traditionally a simple and well understood concept — the Observer Pattern. Making code do something unexpected is likely to confound clients of your class unless the behavior is very narrow and contained in scope. Why solve a problem by injecting specialized behavior into event management when you can solve it somewhere else?

Okay, logging the adding and removing of listeners might make sense. Perhaps even supporting thread synchronization would make sense (you might want to prevent changes in the MulticastDelegate while an event is in the middle of firing).

Still, it seems like something a junior programmer would do just to show off – but unwittingly invite trouble at the same time.

What do you think? Have you used this before? Can you envision any problems where custom event listener management is the ideal solution?