http://alexlabonline.googlecode.com/svn/trunk/WinsockLab/Sio_keepalive_vals/Sio_keepalive_valssrc.cpp

AND
A bitwise AND takes two binary representations of equal length and performs the logical AND operation on each pair of corresponding bits. The result in each position is 1 if the first bit is 1 and the second bit is 1; otherwise, the result is 0. In this, we perform the multiplication of two bits; i.e., 1 × 0 = 0 and 1 × 1 = 1. For example:
0101 (decimal 5)
AND 0011 (decimal 3)
= 0001 (decimal 1)
This may be used to determine whether a particular bit is set (1) or clear (0). For example, given a bit pattern 0011 (decimal 3), to determine whether the second bit is set we use a bitwise AND with a bit pattern containing 1 only in the second bit:
0011 (decimal 3)
AND 0010 (decimal 2)
= 0010 (decimal 2)
Because the result 0010 is non-zero, we know the second bit in the original pattern was set. This is often called bit masking. (By analogy, the use of masking tape covers, or masks, portions that should not be altered or portions that are not of interest. In this case, the 0 values mask the bits that are not of interest.)
If we store the result, this may be used to clear selected bits in a register. Given the example 0110 (decimal 6), the second bit may be cleared by using a bitwise AND with the pattern that has a zero only in the second bit:
0110 (decimal 6)
AND 1101 (decimal 13)
= 0100 (decimal 4)
Because of this property, it becomes easy to check the parity of a binary number by checking the value of the lowest valued bit. Using the example above:
0110 (decimal 6)
AND 0001 (decimal 1)
= 0000 (decimal 0)
Therefore 6 is divisible by two and even.

It is not enabled by OS, but by applicaiton level.  Failed to response KEEP ALIVE packet will result windows RST

http://msdn.microsoft.com/en-us/library/aa925764.aspx

A TCP keep-alive packet is simply an ACK with the sequence number set to one less than the current sequence number for the connection. A host receiving one of these ACKs will respond with an ACK for the current sequence number. Keep-alives can be used to verify that the computer at the remote end of a connection is still available. TCP keep-alives can be sent once every KeepAliveTime (defaults to 7,200,000 milliseconds or 2 hours), if no other data or higher-level keep-alives have been carried over the TCP connection. If there is no response to a keep-alive, it is repeated once every KeepAliveInterval seconds. KeepAliveInterval defaults to 1 second. NetBT connections, such as those used by many parts of the Microsoft networking functionality, send NetBIOS keep-alives more frequently, so usually no TCP keep-alives will be sent on a NetBIOS connection. TCP keep-alives are disabled by default, but Windows Sockets applications can use the SetSockOpt function to enable them.

How to view wireshark KEEP ALIVE and TCP window packet http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

Known TCP problem

http://tools.ietf.org/html/rfc2525#section-2.9

Description
The retransmission timeout is used to determine when a packet has
been dropped in the network.  When this timeout has expired
without the arrival of an ACK, the segment is retransmitted. Each
time a segment is retransmitted, the timeout is adjusted according
to an exponential backoff algorithm, doubling each time.  If a TCP
fails to receive an ACK after numerous attempts at retransmitting
the same segment, it terminates the connection.  A TCP that fails
to double its retransmission timeout upon repeated timeouts is
said to exhibit “Failure to back off retransmission timeout”.

Significance
Backing off the retransmission timer is a cornerstone of network
stability in the presence of congestion.  Consequently, this bug
can have severe adverse affects in congested networks.  It also
affects TCP reliability in congested networks, as discussed in the
next section.

Implications
It is possible for the network connection between two TCP peers to
become congested or to exhibit packet loss at the time that a
retransmission is sent on a connection.  If the retransmission
mechanism does not allow sufficient time before dropping

http://blogs.technet.com/b/nettracer/archive/2010/06/03/things-that-you-may-want-to-know-about-tcp-keepalives.aspx

are hardcoded to 10 and could not be adjusted via the registry.

d) Some special considerations

=> Even if TCP KeepaliveTime and TCPKeepAliveInterval registry keys are set to a specific value (TCPIP driver uses the deafult values even if we don’t set these registry keys from the registry), TCPIP driver won’t start sending TCP Keepalives until Keepalives are enabled via various methods at upper layers (layers above TCPIP driver).

=> Native Socket applications can enable TCP keepalives by using anyone of the following methods:

– setsockopt() with SO_KEEPALIVE option – WSAIoctl() with SIO_KEEPALIVE_VALS option (it’s also possible to change Keepalive timers with this API call dynamically on a per-socket basis)

http://blogs.msdn.com/b/sql_protocols/archive/2006/03/09/546852.aspx

In Windows, as well as many other operating systems, TCP/IP Keep-Alive is not enabled by default. By enabling this, SQL Server can, in a timely manner, detect “orphaned connection” and free up valuable resource associated with each connection, including its session context, locks, kernel TCP buffers and etc., which sometime can become very expensive for a SQL Server running heavy transactions. The major drawbacks, among many others, are (1) Keep-Alive consumes bandwidth on a perfect idle connection; (2) It causes good connection to break during transient network failures. So configuring the keep-alive values too small is not recommended.

The following KB about orphaned connection/session for SQL Server 2000 shares valuable insight on how to configure Keep-Alive for named pipe connections.

http://support.microsoft.com/kb/137983/?sd=RMVP&fr=1,

http://msdn.microsoft.com/en-us/library/aa370652(VS.85).aspx