Discussion :

[Etanne]

Bonjour,

Je suis actuellement entrain de réaliser un serveur en C# et j'utilise donc des Sockets.

Dans mon programme, j'ai créé un Thread chargé de recevoir les données.

Ce thread récupère les données envoyées par chaque client et traite le message.

Son code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
foreach (Socket client in m_Clients.Values)
{
    // Si on a reçu des données
    if (client.Available > 0)
    {
        byte [] buffer = new byte [client.Available];
 
        // Réception des données
        client.Receive(buffer, buffer.Length, SocketFlags.None);
 
        // Transformation bytes -> string
        string message = new System.Text.ASCIIEncoding().GetString(buffer);
 
        // Traitement
        Traitement(message);
    }
}

Mon problème est le suivant :

Imaginons que tous les clients envoient toutes les secondes le message "bonjour".

Si un traitement (fonction Traitement()) prend plus de 3 secondes pour un client, quand je vais faire le Receive pour le prochain client, je vais alors avoir le message "bonjourbonjourbonjour".

Il y a t-il un moyen d'éviter cela, et par exemple imaginer un Receive qui indique que le client a envoyé 3 messages : "bonjour" "bonjour" et "bonjour" ?

Merci !
Flo

[Pol63]

à priori non
c'est pour ca que tout protocole de dialogue (http, ftp etc...) a des normes style caractère de fin de transmission
par exemple utilise #

car d'ailleurs, il n'est pas sur qu'une trame soit envoyé en une seule fois, elle peut très bien etre découpée par les couches tcp ip
donc avec ta technique tu pourrais avoir bon puis jour et ne pas pouvoir interpreter la commande

le principe est donc de concaténer tout ce que tu recois et qui si tu trouves dedans un caractère de fin, tu traite ce qu'il y a avant et tu tronques (puis tu regardes s'il y a encore un caractère de fin

[Tober]

Tu pourrais ajouter un caractere de fin apres un message du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

message + "EndOfMessage"

Bon, c'est pas l'idee du siecle

[Etanne]

Merci pour la réponse.

Je dois donc normaliser mon protocole. Comme tu l'indiques, avec '#' par exemple : "#bonjour#"

J'ai une autre question : comment me protéger d'une attaque DoS dans le programme ?

Merci !

[Pol63]

si ton appli est pas connue, ca sert à rien de s'en préoccuper (enfin si elle est pas publique)


sinon y a doit y avoir des méthodes connues, perso à vu de nez j'aurais quelques idées genre :
garder les connexions ouvertes
si x ouverture de connexion d'une ip => attaque
si x requete par seconde d'une connexion => attaque
ordonner l'ordre des requetes, si requete pas bon ordre à partir d'une connexion => possibilité d'attaque

enfin j'suis loin d'etre un pro en sécurité !!

[Etanne]

Mon serveur sera public, et je crains par avance qu'un petit malin vienne faire une attaque.

Je vais déjà protéger le code pour éviter qu'une IP se connecte plus que X fois au serveur.

Maintenant, si des personnes avec des IP différentes bombardent le serveur..

Merci !!

[Tober]

Je connais pas ton appli, mais deja tu peux limiter le temps entre de connexion d'un meme utilisateur car tu sais qu'un client ne va pas t'envoyer 1 requete toutes les x secondes...
Tout depend de l'appli que tu developpe : si c'est un Messenger, tu peux pas limiter en temps ou tres court, si c'est un envoi de formulaire quotidient, ben tu peux deja elargir la limite
Tu peux aussi limiter le nombre simultanne d'utilisateur ! Du genre, si nombre de client simultanne superieur a x, refuser connexion...
Pense aussi a verifier ce qu'envoi un client, par exemple s'il doit t'envoyer des message genre texte et que tu recois des message de 10Mo, pause toi la question

Voila vite fais quelques idees en plus

[Etanne]

Bonjour,

Merci pour les réponses.

J'ai identifié quelques solutions pour éviter les attaques :

Blacklist :

Blacklister les IP dont on est sur dernière qu'ils s'agissent de personnes malveillantes

Protection à la connexion :

Refuser plus de X connexions provenant de la même adresse IP

Autorisation de parler au client :

La communication est synchrone. Seul le serveur indique au client si il peut parler. Exemple : le client parle, le serveur lui répond qu'il a bien eu le message. Le client devra attendre que le serveur lui indique qu'il puisse parler pour envoyer son prochain message.

Eviter la réception de gros paquets :

Déconnecter les clients envoyant des messages de plus de X bytes

voila...

[theMonz31]

salut

si je peux me permettre....

Le fait de "baliser" tes messages est une bonne chose...

Le fait qu'un traitement puisse etre plus long que le delai entre 2 lectures n'est pas quelque chose d'acceptatble... mais cela peut arriver.
Pour te prémunir de cela, tu "devrais" faire en sorte que ton thread de lecture ne puisse etre bloquer par un traitement. Après tout, son role c'est de lire le contenu du buffer socket et de le mettre à disposition, pas plus.

Pour moi, le traitement pourrait être fait de façon asynchrone... (invoke par exemple)... ce qui "pourrait" t'éviter de telles collisions ou agrégations des messages

C'était juste un avis en passant

The Monz, Toulouse

[Etanne]

Salut,

Merci pour ta réflexion. Je pense donc faire différentes couches

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
----------------------------------------------------
| COUCHE 3 : TRAITEMENT DES DONNÉES                |
----------------------------------------------------
| COUCHE 2 : GESTION DE LA PILE DES DONNÉES REÇUES |
----------------------------------------------------
| COUCHE 1 : RÉCEPTION DES DONNÉES                 |
----------------------------------------------------

La couche 1 (thread) reçoit les paquets, elle est envoie les paquets à la deuxième couche.

La couche 2 (Singleton) s'occupe de la gestion des données (système de pile FIFO).

La couche 3 (thread) récupère les infos dans la pile FIFO.

Qu'en pensez-vous ?

[theMonz31]

salut, ça me parait une bonne solution...

Un thread producteur qui met dans une pile FIFO des messages
Un thread consommateur (traitement) qui regarde si la pile lui propose des choses à traiter...

C'est TRES classique comme architecture et c'est plutôt efficace !

Après, singleton ou variable static, c'est au choix.

The Monz, Toulouse

[Etanne]

Et cela est pareil pour les envois (Cf. PJ) !

Merci à tous pour le coup de pouce !

Florian !

[theMonz31]

n'oublie pas le résolu si tu es content de la solution élaborée collégialement

The Monz, Toulouse

[Etanne]

n'oublie pas le résolu si tu es content de la solution élaborée collégialement

The Monz, Toulouse

Je suis ravi même, maintenant, y'a plus qu'à....

Florian

[wiztricks]

Je dois donc normaliser mon protocole. Comme tu l'indiques, avec '#' par exemple : "#bonjour#"

"Normaliser"? Il faut définir un protocole dans lequel les unités d'informations seront identifiables et grace auquel un client pourra ou pas expédier plusieurs messages à la suite sans que le serveur ne soit confus.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

J'ai une autre question : comment me protéger d'une attaque DoS dans le programme ?

Il me semblerait plus judicieux de traiter cela dans la couche réseau via des fonctions de pare-feux.
Dans le cas d'un programme, le DoS peut se traduire par "combien de clients suis je capable de traiter en même temps pour que les temps de réponses soient raisonnables".

Imaginons que tous les clients envoient toutes les secondes le message "bonjour".

Si un traitement (fonction Traitement()) prend plus de 3 secondes pour un client, quand je vais faire le Receive pour le prochain client, je vais alors avoir le message "bonjourbonjourbonjour".

Il y a t-il un moyen d'éviter cela, et par exemple imaginer un Receive qui indique que le client a envoyé 3 messages : "bonjour" "bonjour" et "bonjour" ?

La question est de savoir comment "multiplexer" la réception des messages, leur traitement et les réponses en faisant en sorte que le design autorise un nombre "quelconque" de clients.

Si "quelconque" est petit, on peut se laisser aller à assicier un thread par client. Si "quelconque" peut devenir "grand", il va falloir choisir entre une mécanique "event driven" ou un design dans lequel les différentes activités vont pouvoir être menée par un nombre minimal de threads.

- W

[Onlava]

Un thread producteur qui met dans une pile FIFO des messages

My 2 cents : il faut pluôt une pile FILO afin de conserver l'ordre des paquets (vu qu'il est garanti par la couche TCP).

++