×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Nathan,
TCP keep-alive packets are used to test whether a connection is still
alive, or whether it has been disconnected.
In the olden days, a direct cable would be connected between computers
(for example, RS-232, Parallel, Twinax, etc). If the connected device
was on, there'd be electricity on the cable. If the device was
disconnected for any reason, the electricity would be gone, so the host
could detect the connection disruption. (For example, if a fuse was
blown, or the cable was cut.)
However, with TCP/IP networks there's no equivalent. A packet (SYN) is
set to indicate the start of the connection, another (FIN) is sent to
end the connection. (I'm oversimplfiying, but you get the idea).
Multiple intermediate packets are sent to send data.
But, if a fuse blows, or the cable is cut, the computer goes down
without ever sending a FIN. How can one computer ever detect that the
other computer has disconnected? It can't tell the difference between
the remote computer being "idle" (not sending anything) and an
unexpected disruption (power loss, cable damage, etc).
That's what keep-alive packets are for. They are sent and acknowledged
periodically to detect whether the connection was dropped.
Note that this is done at a very low-level (inside the TCP/IP stack).
It's not really part of Websockets. Keep-alives can be enabled on any
TCP connection, including PC5250, HTTP, SMTP, XMLHTTPReq,... anything...
On 7/11/2012 5:57 PM, Nathan Andelin wrote:
Web sockets are supposed to be "persistent" connections according to
the specification. Why is the client periodically polling with
keep-alive and other requests? I thought we all agreed that polling
is NOT good!
midrange.com
