High availability without dropping connections

I've also researched how to load balance long-lived telnet connections. Even the big expensive load balancers like F5 don't seem to support "migrating" an open tcp connection from a dead server to another server. I considered capturing the handshake and connection packets from telnet on our load balancer, then replaying those if it had to reconnect to another server. The issue is that every application (telnet, comet, ssh, etc) has a different set of rules for initiating the connection and logging in. Without coding for each application, I don't know of a load balancer that can do such a thing.

In the end, I gave up and invested the time reconfiguring the client application to reconnect to the service in a way that was transparent to the user.

For comet, I suggest you configure the web service to reconnect when it detects a disconnect. This article about HTTP Streaming on ajaxpatterns.org has a code snippet for detecting a disconnect.

Once comet can reconnect, then your current load balancer setup should function as expected.

You can't do it through HAProxy, because that is on the wrong OSI layer - at the HTTP level, instead of at the TCP level. Some of the lower layer load balancers have a feature that may be able to accomplish what you are talking about, at least for many connections, by passing information back and forth from the active node to the passive node. Look at the Linux Virtual Server (LVS) combined with a service level daemon like ldirectord to accomplish what you are looking for.

This isn't really possible. It would be a much better idea to program the client to tolerate server failure and automatically reconnect. This would allow for single server failure, and potentially site failover as well (if a whole site failed).

Hypothetical land: It may be possible to create a client-server dynamic where the intermediate load balancer or proxy could automatically establish a new connection to the failover server, and forward any new traffic to/from the client to that new server. The server would have to be somehow aware of the client's session information, perhaps by storing the session information in shared storage. Alternately the client could be programmed as such to tolerate a server that does not have its prior session information (at long as we're modifying the client we might as well do paragraph 1 and make it simply reconnect to the new failover server). Such a configuration would almost certainly be more complicated and error prone than it's worth.