J'ai entendu parler de l'option HTTP keep-alive, mais pour l'instant, je veux ouvrir une connexion par socket avec un serveur distant.
Maintenant, cette connexion socket restera-t-elle ouverte pour toujours ou y a-t-il une limite de temps associée à cette connexion similaire à HTTP keep-alive ?
Les sockets TCP restent ouverts jusqu'à ce qu'ils soient fermés.
Cela dit, il est très difficile de détecter une connexion interrompue (interrompue, comme dans le cas d'un routeur mort, etc., par opposition à fermée) sans envoyer réellement des données, de sorte que la plupart des applications effectuent une sorte de réaction de type ping/pong de temps en temps, juste pour s'assurer que la connexion est toujours vivante.
Ok, donc l'implémentation doit s'assurer de vérifier à intervalle régulier que la connexion est morte ou vivante, n'est-ce pas ?
C'est une bonne idée. Vous n'avez pas à ont Mais si vous ne le faites pas, vous risquez de ne pas détecter un lien brisé avant que quelqu'un ne veuille vraiment faire quelque chose. Ce qui peut ou non être une bonne chose (ou peut ou non avoir de l'importance), en fonction de ce que vous essayez réellement de réaliser.
Vous recherchez l'option de socket SO_KEEPALIVE.
El API Java Socket expose la fonction "keep-alive" aux applications par l'intermédiaire de l'interface utilisateur. setKeepAlive y getKeepAlive méthodes.
EDIT : SO_KEEPALIVE est implémenté dans les piles de protocoles réseau des OS sans envoyer de "vraies" données. L'intervalle keep-alive dépend du système d'exploitation, et peut être réglé par un paramètre du noyau.
Puisqu'aucune donnée n'est envoyée, SO_KEEPALIVE ne peut que tester la vivacité de la connexion réseau, et non la vivacité du service auquel la socket est connectée. Pour tester ce dernier, vous devez implémenter quelque chose qui implique l'envoi de messages au serveur et l'obtention d'une réponse.
Si j'ai setKeepAlive(true) ; quel serait l'intervalle ?... aussi Java continuera-t-il à envoyer des messages keep-alive à l'intervalle par défaut ou devrai-je le faire par programme ?
unixguide.net/network/socketfaq/4.7.shtml A une description de SO_KEEPALIVE. Ce n'est pas vraiment ce que l'OP voulait, bien qu'il y ait un certain nombre d'avantages. es une option basée sur le protocole à ce que j'ai suggéré... cependant, une fois toutes les deux heures ne fera pas grand chose pour les applications.
Le keepalive TCP et le keepalive HTTP sont des concepts très différents. Dans TCP, le keepalive est le paquet administratif envoyé pour détecter une connexion périmée. En HTTP, le keepalive signifie l'état persistant de la connexion.
Ceci est tiré de la spécification TCP,
Les paquets Keep-alive DOIVENT être envoyés uniquement lorsqu'aucun paquet de données ou d'accusé de réception n'a été reçu pour la connexion dans un intervalle donné. Cet intervalle DOIT être configurable et sa valeur par défaut ne doit pas être inférieure à deux heures.
Comme vous pouvez le constater, l'intervalle TCP keepalive par défaut est trop long pour la plupart des applications. Vous devrez peut-être ajouter le keepalive dans votre protocole d'application.
Vous pouvez modifier l'intervalle TCP keepalive en fonction de votre application. Par exemple msdn.microsoft.com/fr/us/library/dd877220%28VS.85%29.aspx
@ZZCoder Pouvez-vous préciser ce que vous entendez par "En HTTP, keepalive désigne l'état persistant de la connexion" ?
@Pacerier : Sur HTTP/1.0 chaque demande/réponse nécessitait de se reconnecter au serveur. Pour HTTP/1.1 ils ont introduit un Keep-Alive qui pourrait être utilisé pour inciter le serveur à ne pas couper la connexion après avoir traité la réponse, afin de faciliter la demande d'autres fichiers et de permettre le "pipelining", c'est-à-dire l'envoi de plusieurs demandes et l'attente du retour de toutes les données.
Si vous êtes derrière un NAT de masquage (comme c'est le cas de la plupart des utilisateurs à domicile de nos jours), le nombre de ports externes est limité et ils doivent être partagés entre les connexions TCP. Par conséquent, les NAT de masquage ont tendance à supposer qu'une connexion a été interrompue si aucune donnée n'a été envoyée pendant un certain temps.
Ce problème, ainsi que d'autres problèmes de ce type (n'importe où entre les deux points d'extrémité), peut faire que la connexion ne "fonctionne" plus si vous essayez d'envoyer des données après une période d'inactivité raisonnable. Cependant, vous ne le découvrirez peut-être pas avant d'avoir essayez pour envoyer des données.
Utilisation de keepalives à la fois réduit Cela réduit les risques d'interruption de la connexion à un moment donné et vous permet de détecter plus rapidement une rupture de connexion.
Ah ! vous ajoutez un bon point ici, c'est-à-dire qu'il faut aussi prendre en compte les choses intermédiaires qui peuvent entraver le fonctionnement d'une connexion comme les routeurs NAT etc....
C'est un bon point, et un bon rappel qu'il y a plus à garder à l'esprit que ce que nous mettons directement en œuvre nous-mêmes. Aussi, Lemmings !!
Notez que le partage de fichiers p2p consomme beaucoup de ports et produit beaucoup de connexions zombies, ce qui rend plus probable la nécessité pour le NAT d'élaguer les connexions inactives.
Voici de la documentation supplémentaire sur keepalive qui l'explique de manière beaucoup plus détaillée.
http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO
Comme Java ne vous permet pas de contrôler les temps réels de keepalive, vous pouvez utiliser les exemples pour les modifier si vous utilisez un noyau Linux (ou un système d'exploitation basé sur proc).
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
2 votes
Pour être sûr, "http keepalive" n'est généralement pas lié à socket keepalive, il s'agit de la fonctionnalité HTTP/1.1 qui consiste à garder les connexions ouvertes pour d'autres demandes. Elle n'est liée à la fonction TCP keepalive que dans la mesure où elle doit détecter les connexions TCP interrompues (ou ne maintient normalement les sockets ouvertes que pendant un temps limité).