[gull] socket en C

[Leopoldo Ghielmetti]

Il giorno gio, 15/05/2008 alle 10.21 +0200, Yann Sagon ha scritto:
> Leopoldo Ghielmetti a écrit :
> > Il giorno mer, 14/05/2008 alle 16.42 +0200, Marc Mongenet ha scritto:
...
> > Exact. Il faut faire un accept et traiter la connexion. La boucle qui
> > fait les accept doit toujours tourner, simplement si le nombre maximum
> > de connexion autorisées est atteint, la boucle peut envoyer un message
> > et déconnecter juste après.
> > Regarde aussi du côté du nombre de client en attente sur le socket (je
> > ne me rappelle plus comment s'appelle le paramètre, mais ça à a voir
> > avec un paramètre listener ou qqc. comme ça), 
> dans listen tu peux spécifier le "backlog" soit les clients en attente, 
> je pense que c'est de ça que tu parles? C'est 5 normalement.

Oui, c'est exactement de ça. Tout dépend de combien de client en attente
tu t'attends. 5 est suffisant, si par contre tu risque d'avoir des rush
de 10 ou 20 clients à la fois alors il est peut-être préférable
d'augmenter la valeur pour avoir le temps de traiter les connexions.
Mais je pense que c'est un paramètre que tu peux régler uniquement après
experience.

> > Fais aussi très attention aux paquets "fragmentes" lors-ce que tu traite
> > tes read/write sur le socket, ne fais jamais de suppositions sur les
> > données envoyés ou reçues, même si c'est ton code qui les envoie, il est
> > toujours possible que tu fais un write("toto\n") et que de l'autre côté
> > tu reçois un "to" et une seconde après "to\n", ou que tu fais
> > write("toto\n"); sleep(1000);write("titi\n") et que tu reçois "toto
> > \ntiti\n" en un seul coup.
> >   
> C'est une application qui sera utilisée sur un réseau local, il n'y aura 
> (en principe) jamais de fragrmentation.
> Mais effectivement, vaut mieux prévoir..

Détrompes toi, on a eu ce problème sur un réseau local à 1Gbps entre 2
machines sur le même switch. Et ce uniquement parce qu'une machine était
un Xeon 3GHz et l'autre un Pentium III à 800MHz (ou quelque chose du
style).
Quand le Xeon envoyait ses paquets, le Pentium les mettait en queue car
il n'arrivait pas à les traiter, donc on se retrouvait avec les paquets
concaténés. Quand le Pentium envoyait des paquets au Xeon, si le message
était assez gros, le message était coupé par le Xeon car il était trop
rapide et il commençait à traiter le paquet avant que le Pentium ait
terminé la transmission.
Il faut aussi considérer que le système d'exploitation peut décider
d'envoyer une partie du buffer pour des questions bien à lui, même si
aucun "\n" n'a été transmis ou aucun flush n'a été demandé.

C'est pour ça que je dis qu'il ne faut jamais faire des suppositions sur
la façon dont les données sont envoyées ou reçues, tu met à jour une
machine, un OS ou tu changes un switch et tout foire.

ciao, Leo