Benvenuto nella nostra community, registra un account gratuito ADESSO!
Oltre 7000 persone hanno già registrato il loro account. Chiedi aiuto, conversa con aziende ed esperti del settore webhosting italiano.
Iscriviti subito! In meno di 2 minuti!




Risultati da 1 a 6 di 6
  1. #1
    Uno
    Uno non è collegato
    Utente Moderatore
    Data Registrazione
    Mar 2008
    Messaggi
    5,793

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

    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...



  2. #2
    Nuovo utente
    Data Registrazione
    Apr 2009
    Messaggi
    9

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

    Citazione Originariamente Scritto da guest Visualizza Messaggio
    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 )

  3. #3
    Provider L'avatar di guest
    Data Registrazione
    Nov 2007
    Località
    Riccione
    Messaggi
    6,311

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

    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
    http://www.web4web.it - Low Cost Hosting
    Tutti i pacchetti sono multidominio.
    Database e domini illimitati a partire da €10


    http://www.guest.it - Servizi professionali su misura.

  4. #4
    Provider L'avatar di guest
    Data Registrazione
    Nov 2007
    Località
    Riccione
    Messaggi
    6,311

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

    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
    http://www.web4web.it - Low Cost Hosting
    Tutti i pacchetti sono multidominio.
    Database e domini illimitati a partire da €10


    http://www.guest.it - Servizi professionali su misura.

  5. #5
    Nuovo utente
    Data Registrazione
    Apr 2009
    Messaggi
    9

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

    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..

  6. #6
    Provider L'avatar di guest
    Data Registrazione
    Nov 2007
    Località
    Riccione
    Messaggi
    6,311

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

    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*
    ?
    http://www.web4web.it - Low Cost Hosting
    Tutti i pacchetti sono multidominio.
    Database e domini illimitati a partire da €10


    http://www.guest.it - Servizi professionali su misura.

Discussioni Simili

  1. Bench The Cloud: valutare le performance dei servizi di cloud computing
    Di Redazione HostingTalk nel forum Articoli e news su Webhosting e Servizi Internet
    Risposte: 0
    Ultimo Messaggio: 03-08-2010, 07:00
  2. VENDO GRUPPO CONTINUITA' APC SMART
    Di marco.wella nel forum Hardware
    Risposte: 0
    Ultimo Messaggio: 29-05-2010, 13:59
  3. Continuità di servizio
    Di alfaalex nel forum Domini e Registrazioni
    Risposte: 2
    Ultimo Messaggio: 15-05-2009, 19:47
  4. Blade Server - Le “lame” che hanno rivoluzionato il modo di intendere il server rack
    Di Redazione HostingTalk nel forum Interviste & contenuti professionali
    Risposte: 0
    Ultimo Messaggio: 08-05-2009, 11:02
  5. Cambiare server (e predisporre altri cambiamenti) nel modo più indolore possibile
    Di Uno nel forum Gestione Server Windows e Server Linux
    Risposte: 11
    Ultimo Messaggio: 17-09-2008, 08:58

Informazioni Discussione

Utenti che Stanno Visualizzando Questa Discussione

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tag per Questa Discussione

Segnalibri

Permessi di Scrittura

  • Tu non puoi inviare nuove discussioni
  • Tu non puoi inviare risposte
  • Tu non puoi inviare allegati
  • Tu non puoi modificare i tuoi messaggi
  •