Discussion :

[Invité]

Bonjour,
Dans le but de développer mes connaissances en programmation, j'ai décidé de coder un chat en C# / WPF.
J'ai regardé une vidéo Youtube qui montrait l'utilisation de Sockets pour une communication TCP avec un serveur qui traite les données et des clients qui envoient les données (

).
Le truc, c'est que je ne vois pas l'intérêt d'utiliser cette technique sachant qu'une base de données SQL est beaucoup plus facile à gérer au niveau des requêtes.
Si vous avez une explication à me fournir, je suis preneur.
Merci de votre réponse.

[François DORIN]

Bonjour,

Principalement pour deux raisons.

La première, c'est d'un point de vue séparation des couches. Cela permet de découpler l'application du modèle physique de données. Outre les avantages que cela peut avoir au niveau de la maintenance (possibilité de mettre à jour le schéma de la base de données sans avoir à mettre à jour les applications clientes), cela permet de gérer plus facilement d'autres opérations comme le changement de base de données (changement de version, voir carrément changement de SGBD).

La seconde, c'est d'un point de vue sécurité. Si un bon SGBD permet de gérer une sécurité assez fine, sécuriser une base ainsi nécessite une bonne connaissance du SGBD en question, afin de permettre à l'utilisateur qui se connecte de n'avoir accès qu'aux informations / opérations qui le concernent. C'est beaucoup plus facile de gérer la sécurité en partant du principe que l'utilisateur n'a accès à rien et on lui donne progressivement les droits (WebService) que d'avoir un utilisateur avec tous les droits et de les restreindre au strict nécessaire (SGBD) (pour les puristes des SGBD, je fais un grossier raccourci volontaire ici, la personne étant débutante).

[Noxen]

Parce-que tu as l'intention de donner aux utilisateurs les droits d'accès à la base de données peut-être ?

Et puis de toute façon ce sont deux notions qui n'ont rien à voir. Un logiciel de chat c'est avant tout des échanges de messages entre différentes applications. Typiquement des clients se connectent à un serveur qui se charge ensuite de dipatcher des messages ; mais ça n'implique pas forcément une base de données. Il est possible de déléguer la gestion des utilisateurs à un fournisseur d'identité ; rien n'oblige à sauvegarder les messages échangés ; le serveur peut être un simple annuaire dynamique et les clients de messagerie se connectent ensuite directement sans passer par le serveur.

[PixelJuice]

Bonjour,

Il faudrait préciser quel genre de chat tu veux faire ? Car il y une multitude de structures différentes. Un salon ? Des salons ? Un Messenger avec contacts ? etc ...

Envoyer des données directement à une BDD depuis le client ce n'est pas vraiment une bonne idée. Sans compter que comme dit plus haut, il faut une séparation très nette des couches sinon ça va vite être la foire à la saucisse.

Une structure client / serveur est là pour imposer un maximum de restrictions aux clients, et pour que le serveur est un contrôle total sur ce qui transite par lui. Ça ne parait pas évident pour une simple application de chat mais ça l'est pour un jeu en ligne par exemple.

Imagine que je trifouille la mémoire d'un jeu pour me mettre un maximum d'argent et que j'essaye d'acheter un objet. Le client (le jeu) va valider cet achat car pour lui je suis riche et va donc autoriser l'envoi d'une requête au serveur. Le serveur va recevoir ma requête, sauf que lui de son coté, il va regarder dans la BDD et voir que je n'ai pas autant d'argent que je prétends, et que je ne peux pas acheter cet objet. Du coup il me refuse l'achat et peut même me bannir directement pour tentative de triche. Sans le serveur, la triche fonctionne parfaitement.

En programmation, il faut toujours partir du principe que tes utilisateurs veulent foutre ton logiciel en l'air par tous les moyens possibles.

[StringBuilder]

Même si c'est pas une bonne pratique, j'avoue que les arguments à l'encontre de l'exécution directe en base de données me laisse perplexe.


1/ Gestion de la sécurité
Même si c'est plus lourd, il est largement préférable d'avoir une gestion fine des droits au niveau utilisateur (ou au niveau groupe utilisateur) directement dans la base de données plutôt que sur l'application Serveur. En effet, si on a un droit fourre tout, qui sert aussi pour les opération d'administration, alors un client peut parfaitement, en trouvant une exploit, exécuter du code SQL avec tous les droits depuis son poste, sans avoir la moindre idée du mot de passe administrateur. C'est le principe même de l'injection SQL.

2/ Séparation des couches
ODBC, OLEDB ou le connecteur natif .NET sont une couche de transport (plus évoluée, certes), au même titre que Socket ou WebSocket. Pas conséquent, passer par une requête Socket pour transporter un ordre "donne-moi les produits qui commence par A", je ne vois pas trop ce que ça change de passer par l'une ou l'autre des méthodes. Le seul véritable intérêt, sur les mauvais SGBD, serait la possibilité d'intercepter ces demandes dans l'applicatif serveur afin de déverse des données en cache plutôt que d'interroger le SGBD. Mais avec les SGBD modernes, entre l'utilisation de leur propre cache et les tables "in memory", gérer du cache côté applicatif n'apporte plus grand chose d'autre que de la lourdeur (en maintenance et exécution) et des soucis (cache pas à jour, etc.)

Si on veut séparer "proprement" les couches et garantir qu'un utilisateur ne peut pas effectuer des opérations auxquelles il n'a pas droit, il suffit de travailler proprement sans balancer du SQL à tout va au SGBD, mais en utilisant procédures stockées et vues pour accéder aux données.
Si on révoque les accès CRUD (INSERT/SELECT/UPDATE/DELETE) sur toutes les tables, qu'on publie des vues en lecture seule, et qu'on ne peut modifier les données que par l'intermédiaire de procédure stockées, alors il n'y a pas d'injection SQL possible, pas de bidouille du genre "oué je vais faire croire que je suis Crésus alors que c'est pas vrai", et aucun risque, ou presque, à exposer directement la base de données.
Le seul vrai risque c'est qu'une personne extérieure qui réussi à récupérer le compte administrateur (genre un ancien salarié pas content) peut accéder à toute la nase de données depuis l'extérieur, ce qui en soit n'est pas terrible… à noter qu'avec la mode du cloud, on prend ce risque et c'est pourtant très en vogue).


Bref, non, le seul "vrai" argument que je vois qui va à l'encontre de faire un chat en SQL, c'est avant tout qu'un SGBD ne sait pas notifier les différents clients lorsqu'une donnée change.

Ainsi, chaque client va passer son temps à recharger la liste des messages pour voir s'il n'y a pas du nouveau depuis la dernière seconde… ce qui va rapidement foutre en l'air les performances du serveur (ne serait-ce qu'en saturant la bande passante) WAN.
Avec Socket, les clients ont tous une connexion ouverte en attente de donnée, et seront donc notifiés "en temps réel" de l'arrivée d'un message dans la chatroom.

[lead8209]

Bref, non, le seul "vrai" argument que je vois qui va à l'encontre de faire un chat en SQL, c'est avant tout qu'un SGBD ne sait pas notifier les différents clients lorsqu'une donnée change.

Ainsi, chaque client va passer son temps à recharger la liste des messages pour voir s'il n'y a pas du nouveau depuis la dernière seconde… ce qui va rapidement foutre en l'air les performances du serveur (ne serait-ce qu'en saturant la bande passante) WAN.
Avec Socket, les clients ont tous une connexion ouverte en attente de donnée, et seront donc notifiés "en temps réel" de l'arrivée d'un message dans la chatroom.

Dernièrement j'ai expérimenté la commande NOTIFY sur posgres.
Le principe c'est d'appeler la commande notify côté serveur sql posgres à partir d'un trigger déclenché sur l'UPDATE d'un champ ou l'insert dans une table etc..
Dans mon cas une tâche secondaire sur une application (client lourd ou webserver pour moi) écoute sur une connexion les notifications en provenance de la base. Elle réceptionne les notifications et les valeurs (sérialisées en json par exemple)
Avec la techno signalr j'ai même pu notifier le changement de valeur à tous mes clients web et ainsi rafraîchir uniquement le champ correspondant.

[StringBuilder]

Dernièrement j'ai expérimenté la commande NOTIFY sur posgres.
Le principe c'est d'appeler la commande notify côté serveur sql posgres à partir d'un trigger déclenché sur l'UPDATE d'un champ ou l'insert dans une table etc..
Dans mon cas une tâche secondaire sur une application (client lourd ou webserver pour moi) écoute sur une connexion les notifications en provenance de la base. Elle réceptionne les notifications et les valeurs (sérialisées en json par exemple)
Avec la techno signalr j'ai même pu notifier le changement de valeur à tous mes clients web et ainsi rafraîchir uniquement le champ correspondant.

Cette fonctionnalité sort du cadre du simple SGBD : c'est hors norme SQL et spécifique à PostgreSQL (même si les autres SGBD du marché intègrent aussi ce genre de chose). Ca ne passera pas par les couches de transport des données que sont ODBC, OLEDB ou connecteur natif .NET

PS : SignalR est ni plus ni moins qu'une alternative à Socket (voir même une encapsulation). Rien à voir avec le SGBD, tu peux tout à fait faire ton chat avec un serveur SignalR seul.

Au passage, j'aimerais bien une explication sur ce qui m'a valu un -1