Il miglior modo per valutare la continuità dei servizi di un server

[Uno]

Come da oggetto.....
E' uscito in un 3d (http://www.hostingtalk.it/forum/serv...con-ovh-4.html) in cui non c'entrava nulla, qualcuno proponeva sistemi appoggiati al protocollo irc, altri lo hanno contestato...
Ma in sostanza per sfizio cosa potremmo usare per verificare la continuità di una rete, o meglio quanto una certa macchina è ben collegata al resto del mondo.
Si lo so che ci sono strumenti software appositi, ma stupitemi
Chi risponde "ping".... è meglio che non dico...

[bago]

Ma anche io stavo parlando di TCP.
E da RFC1122 il keepalive minimo (che di default NON deve essere attivato) è pari a 2 ore.
Tenere 5 giorni è insensato, anche perchè di default NON è attivato per cui bisogna attivarlo volutamente pari a 5 giorni.

No, che sappia io non è così. Il keepalive è proprio quello che fa cadere la connessione se non c'è più il collegamento funzionante. Se non fosse per il keepalive e per timeout di protocollo potresti tranquillamente superare le 2 ore. Il keepalive fa la duplice funzione di impedire il timeout per mancanza di dati e di scatenare una disconnessione nel caso di reale mancanza del collegamento.

L'rfc1122 nella sezione Keep-Alive "discussion" dice infatti che il keepalive non fa parte dei requisiti perchè "it could: (1) cause perfectly good connections to break during transient Internet failures;" (potrebbe rompere una connessione "buona" per colpa di un problema temporaneo di internet).

Dice anche:

A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure.

Che conferma che senza il keepalive la connessione potrebbe rimanere aperta molto più di 2 ore (5 giorni, appunto) e il keepalive è stato introdotto proprio per evitare di sprecare risorse nel tenere riferimenti a connessioni morte.

Mi sembra che siamo caduti in "tecnicismi teorici" e poco utili nella pratica. La maggior parte dei protocolli basati su TCP prevede timeout ben più bassi (tipo 15-30 minuti) e meccanismi di keep-alive applicativi (NOOP, tipicamente). Anche detto questo, però, rimane il fatto che è MOLTO FREQUENTE che un down di 2 secondi (ma anche di 5 minuti) alle trasmissioni non provochi la disconnessione di una connessione, che poi era il cuore della discussione (o almeno lo è ora che abbiamo cambiato Topic )

[guest]

Ma chi dice che una connessione resta in established per 5 giorni?
Una connessione ci resta per tutto il tempo che vuoi, non deve cadere dopo 5 giorni.
Nel caso fosse rimasta "appesa" senza controllo (l'altro nodo non ha inviato il FIN per la chiusura) il keepalive entra in funzione inviando un ACK ogni 75 secondi a partire da 2 ore di inattività.
Se dopo 9 volte di fila il client non risponde agli ACK del server, la connessione si identifica come morta e viene abbattuta.

Ed è normale che rompa una connessione buona in caso di errori temporanei. Se per 11 minuti il server non riceve risposta dal client, la connessione viene abbattuta.
Il keepalive TCP serve a monitorare l'esistenza dello stream ed eventualmente abbatterlo se è morto, e non va confuso con un keepalive "tradizionale" che serve a non fare cadere le connessioni.
Che io sappia, non esiste alcun limite a 5 giorni per le connessioni established.
Anche perchè, per quale motivo tu dovresti chiudere la mia connessione dopo 5 giorni?
Se non c'è attività la chiudi dopo 11 minuti (se il keepalive è in funzione), se c'è attività (oppure keepalive non in funzione), tu devi lasciare la mia connessione attiva per 40 anni finchè non ricevi un FIN o un RST

[guest]

effettivamente nel conntrack di linux c'è un timeout di 5 giorni ma credo sia una implementazione di linux e non uno standard tcp.
mi documento e poi dico

[bago]

Sia windows che linux se non attivi keepalive e se non fai alcun traffico sulla connessione dopo 432000 secondi ti chiudono la connessione. Sono sempre stato convinto fosse una specifica TCP ma al momento non ne trovo la prova. Però sono sicuro che le implementazioni di windows e linux usano esattamente 432000 secondi e sconsigliano la modifica..

[guest]

Di Windows non ci capisco niente, per cui non dico nulla.
Mentre invece, su Linux, non vorrei dire una stronzata ma credo che tali limiti siano parametri del conntrack del netfilter. Per assurdo un kernel senza supporto conntrack o netfilter non dovrebbe nemmeno essere soggetto a tali timeout.

Dubito sia una specifica del TCP, credo siano delle implementazioni (più o meno standard) dei vari sistemi operativi, altrimenti che senso avrebbe metterle in
/proc/sys/net/ipv4/netfilter/ip_conntrack_*_timeout*
?