neerma@cod.NOSC.MIL (Merle A. Neer) (12/07/89)
I need some clarification on the TCP spec in a couple of areas. 1. Is 'keepalive' a TCP option or merely a implementation feature? Where is it documented. 2. What should the behavior of a sending TCP be once it has retransmitted a segment a maximum number of times? What is the maximum number of times? Assuming it should close the connection, should it inform the user? Thanks, Merle neerma at nosc.mil 619-553-3974
dzoey@TERMINUS.UMD.EDU (12/08/89)
> From: "Merle A. Neer" <neerma@cod.nosc.mil> > To: pcip@twg.com > 1. Is 'keepalive' a TCP option or merely a implementation > feature? Where is it documented. Keepalives are an implementation decision and popular discussion topic on the TCP/IP mailing list. 4.2 BSD used keepalives to determine the status of connections. The pros of keepalives are that it can be used to detect stale connections and can "clean up and free resources" if it finds a stale connection. It works well in a LAN environment where the extra traffic is not noticible and hosts respond quickly. The cons are that keepalives don't handle the case where both hosts are up, but the network is temporarily down or response time has dropped dramitically (typical of WAN). They add unnecessary traffic to a (over)congested link and sever good connections due to temporary network problems. > 2. What should the behavior of a sending TCP be once it > has retransmitted a segment a maximum number of times? I'd abort the connection and report an error back to the user. > What is the maximum number of times? Good question. There are some who maintain that connections should never time out because if a host goes down, when it comes back up it will lose information about the old connection and send a reset when it receives a packet from the old connection. If the network was just flakey the connection will continue where it left off. On machines with limited resources (PCs), You can go around and kill off old connections when a new connection is needed (where old is defined as retransmits greater than N (maybe 10?)). If the connection is attatched to an interactive process, the user can always hit break to abort the application (and the connection). > Assuming it should close the connection, should it > inform the user? Sure, why not? Joe Herman University of Maryland -- Everything is wonderful, until you know something about it.