[gull] socket en C

Christian ALT calt at tla.ch
Thu May 15 11:33:08 CEST 2008


Bonjour,

Désolé si je sauté dans la discussion sans avoir lu tout le détail, mais lorsque je lis qu'une application sur un réseau local dépend du type de machine ou de son OS cela me fait m'interroger. Vos sockets travaillent sur UDP ou TCP?

La différence c'est le mode orienté connexion ou pas. UDP est coûteux sur un réseau ou il y a des erreurs de transmission ou des congestions. Ce qui caractérise votre cas. Et surtout que le contrôle de flux doit être géré au niveau de l'application. C'est ce qui manque dans ce que je comprends de votre problème et qui me fait réagir.

C'était une remarque en vitesse.

Bonne journée,


Christian ALT

Telecom and Logistics Associates
Network Security Company
Security Lead Auditor for ISO 27001
http://www.tla.ch
Agenda Romand de la formation IT et Securité
http://www.tla.ch/agenda.htm 




-----Original Message-----
From: gull-bounces at forum.linux-gull.ch [mailto:gull-bounces at forum.linux-gull.ch] On Behalf Of Leopoldo Ghielmetti
Sent: jeudi, 15. mai 2008 11:07
To: GULL (Liste technique)
Subject: Re: [gull] socket en C


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 autorises est atteint, la boucle peut envoyer un message
> > et dconnecter juste aprs.
> > Regarde aussi du ct du nombre de client en attente sur le socket (je
> > ne me rappelle plus comment s'appelle le paramtre, mais a  a voir
> > avec un paramtre listener ou qqc. comme a), 
> dans listen tu peux spcifier 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 dpend 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 prfrable
d'augmenter la valeur pour avoir le temps de traiter les connexions.
Mais je pense que c'est un paramtre que tu peux rgler uniquement aprs
experience.

> > Fais aussi trs attention aux paquets "fragmentes" lors-ce que tu traite
> > tes read/write sur le socket, ne fais jamais de suppositions sur les
> > donnes envoys ou reues, mme si c'est ton code qui les envoie, il est
> > toujours possible que tu fais un write("toto\n") et que de l'autre ct
> > tu reois un "to" et une seconde aprs "to\n", ou que tu fais
> > write("toto\n"); sleep(1000);write("titi\n") et que tu reois "toto
> > \ntiti\n" en un seul coup.
> >   
> C'est une application qui sera utilise sur un rseau local, il n'y aura 
> (en principe) jamais de fragrmentation.
> Mais effectivement, vaut mieux prvoir..

Dtrompes toi, on a eu ce problme sur un rseau local  1Gbps entre 2
machines sur le mme 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
concatns. 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 commenait  traiter le paquet avant que le Pentium ait
termin la transmission.
Il faut aussi considrer que le systme d'exploitation peut dcider
d'envoyer une partie du buffer pour des questions bien  lui, mme 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 faon dont les donnes sont envoyes ou reues, tu met  jour une
machine, un OS ou tu changes un switch et tout foire.

ciao, Leo

_______________________________________________
gull mailing list
gull at forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 269.23.16/1433 - Release Date: 14.05.2008 16:44
 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 269.23.16/1433 - Release Date: 14.05.2008 16:44
 





More information about the gull mailing list