Talk:Keepalive

Facebook keepalive should be moved out of this page

This page should be reserved for protocol-related details. The Facebook feature is something completely different and should be moved out. Furthermore, IMHO Facebook has not yet achieved maturity for having its sub-features listed anywhere other than its own site. Todd (talk) 22:52, 26 December 2008 (UTC)

Two somewhat different meanings of the term

The external link is to a page on a somewhat different subject than the (short) article.

The article is about simply validating that another machine is still out there (and is completely uncited). The external link is about HTTP keepalive, which adds persistent connection to the HTTP protocol. - 207.246.150.86 (talk) 22:29, 21 April 2008 (UTC)

Seconded. The phrasing "In Internet, by default Keepalive is set as 2 hours" is vague, and the statement that the link is considered down if no answer is received is merely incorrect. What is more, using TCP/IP Keep-Alive messages is condemned by the standard. Please, see part 4.2.3.6 "TCP Keep-Alives" of RFC 1122 for details. - 195.148.30.59 (talk) 14:23, 8 June 2008 (UTC)

Thirded. HTTP persistent connections are quite different from the TCP-Keepalive mechanism. I will move that to an "Other uses" section. The default of at least 2 hours is specified in RFC 1122. I wouldn't say that RFC 1122 "condemns" keep-alive messages. It argues why they should be off by default, but it explicitely allows and formalizes their use - and besides the internet has become a bit more dynamic since 1989. — Preceding unsigned comment added by Ligneus (talk • contribs) 15:35, 18 June 2015 (UTC)

Ethernet?

What is this thing about Ethernet frame lengths? They are padded to 64 bytes, so where do the claims of 60 and 54 bytes come from? — Preceding unsigned comment added by82.146.125.129 (talk) 13:04, 8 February 2012 (UTC)

It is not uncommon to talk about smaller frames. The 64 byte minimum us enforced by Ethernet controllers which automatically pad frames shorter than 64 bytes to 64 bytes. ---—Kvng 17:36, 14 March 2013 (UTC)

Merger Discussion

Merge Discussion

Request received to merge articles: Heartbeat (computing) into Keepalive; dated November 2015. Discuss here. GenQuest "Talk to Me" 06:59, 28 November 2015 (UTC) Don't merge. TCP keepalive is a different concept than heartbeat, and is used in very very different scenarios. So: heartbeat is used to perform failover of redundant systems; the heartbeat could be done by a large variety of protocols, anything from serial lines to PCIe lanes. (e.g. the PCIe spec has a large variety of fail conditions that get managed in the root port; PCIe error recovery deals with rebooting the PCI card if there's no heartbeat.) It there's no heartbeat, the dead system gets rebooted, or maybe the living system takes over from the dead one (for the case of symmetric redundant failover). By contrast, keepalive is simply a mechanism to try to keep a connection open between a tcp client and a tcp server. Its used to check the link between the two, possibly to reset the link if the link is down, and not to reboot either the client or the server, nor to take over operations of one or the other. Put another way: keep-alive validates the link; heartbeat validates the end-points. A dead link is a very different error condition than a dead endpoint. 67.198.37.16 (talk) 18:34, 2 December 2015 (UTC)

•  Not done Only commenter explains that the merge should not take place. GenQuest ^{"Talk to Me"} 01:42, 15 February 2016 (UTC)