[gull] socket en C

Daniel Cordey dc at mjt.ch
Wed May 14 16:00:35 CEST 2008


On Wednesday 14 May 2008, Yann Sagon wrote:

> comment détecter la perte de connexion d'un client? Dans mon cas, je
> suis en attente sur un "select" en surveillant un set "readfds".
> Normalement, le client quite en envoyant une commande, mais dans le cas
> d'une déconnexion brutale, comment terminer proprement? Faut-il voir du
> côté d'un timeout?

Une connexion "socket" est faite a l'aide du protocole TCP. Dans ce ca, la 
gestion de la perte de la connexion est effectuee par la librairie gerant ce 
protocole. La perte de la connexion engendre un signal :

	SIGPIPE

Je recommande aussi d'utiliser un timeout qui permet de traiter tout autre 
type d'interruption a un niveau plus logique. 
	
> J'ai également le problème suivant: si un client tente de se connecter
> sur ma socket et que j'ai atteint le nombre maximale de client,
> j'aimerais notifier le client. Y a t'il un moyen sans faire de "accept"
> préalablement? Et également, comment refuser ce client?

Il n'y a pas de solution simple... Il faudrait passer par la connexion a un 
autre daemon, charge uniquement de faire un forward de l'etablissement de la 
connexion. Il existe la plusieurs techniques transparentes ou non, qui vont 
du renvoi a un autre port autorise au mechanisme du style proxy. Idealement, 
le daemon de front-end devrait comptabiliser les connexion et renvoyer les 
infos necessaires pour etablir le lien. Dans ce cas, le daemon serait 
toutjousr en mesure (sauf DOS) de repondre quelque chose. 

Il faudrait voir dans les codes sources des daemon connus (*ftp, etc.) qui 
sont parfois capables de repondre que le nombre de connexions autorisees a 
ete epuise. Toutefois, sachant qu'il n'existe aucun mechanisme dans *inetd , 
ou les sockets, permettant ce genre de signalisation, je suspecte que le 
daemon se reserve quelques connexions afin de repondre rapidement aux 
requetes dans ce genre de situation. Sachant qu'un telle reponse est 
extremement rapide et que le socket est immediatement ferme, le daemon est 
capable de repondre assez bien dans ce genre de situation. Tout compte fait, 
c'est sans doute la solution la plus simple. Inconvenient, ce traitement doit 
faire partie du code de l'application.

dc






More information about the gull mailing list