Discussion :

[Neckara]

Bonjour,

Je suis en train d'essayer de programmé la partie serveur d'un jeux et je me pose plusieurs questions sur le C dans le but de consommer un minimum de ressource tout en étant le plus rapide possible :

1) Pour vérifier qu'un serveur est en ligne, je peux établir une socket toutes les minutes pour chaque client (sans qu'ils se soient connectés), mais n'y a-t-il pas de méthodes moins coûteux?

2) Pour ce qui est des ports, faut-il associer un port par client? un port pour x client? (si oui comment choisir ce x?) ou un port pour tous les clients?
J'ai fait quelques recherches, et il semblerait que les n° de ports servent à définir l'application de destination du message pour éviter de "s'embrouiller" mais chaque client aura un processus dédiés au traitement de ses messages.


3) Pour la communications entre processus, on a les tubes et la mémoire partagée.
Les tubes sembles intéressant pour la discutions de processus 2 à 2 et la mémoire partagée pour la discutions entre un grand nombre de processus.
Mais quels sont les avantages et les défauts de chacun?

4) Pour les tubes, il me semble qu'on fait un fopen("nom", "w") et un fopen("nom", "r") pour le créer mais plus le tube sera utiliser plus il va "grossir", comment faire pour vider le début dont on a pas besoin?
(il faut aussi faire un fopen("nom", "r") après chaque modification il me semble non?)

5) Beaucoup de processus du serveur vont fonctionner par scrutation, c'est assez dommage...
J'ai dans l'idée de leur faire des sleep(x) s'ils se réveillent au bout de x secondes, ils font un "time out"
Et lors de la réception d'un message, un interruption réveille (SIGCONT) le processus concerné qui traitera le message et réveillera les autres processus impliqués. Est-ce une bonne idée?

J'essaye de faire des recherches internet, mais je n'arrive pas à trouver des explications plus approfondies qui me permettrais de trouver les réponses à mes questions.

Merci de m'avoir lu,

Neckara

[baccali]

Salut,

La première chose que j'ai à dire c'est que la plupart des questions que tu poses ne sont pas claires. J'ai fais aboutir un projet similaire donc je vais essayer d'apporter ma modeste contribution et te dirai quand je suis pas sûr d'avoir compris.

1) Pour vérifier qu'un serveur est en ligne, je peux établir une socket toutes les minutes pour chaque client (sans qu'ils se soient connectés), mais n'y a-t-il pas de méthodes moins coûteux?

Tu peux toujours faire un petit protocole basé sur de l'UDP qui marchera un peu comme un ping. Tu bind ton serveur sur la socket et lorsque le client veut vérifier si le serveur est là il envoie un packet sur le port et si le serveur ne répond pas c'est qu'il n'est pas en activité. Je t'aurais bien proposé un broadcast mais cette solution a pour avantage de ne pas restreinte ton serveur au sous-réseau.

2) Pour ce qui est des ports, faut-il associer un port par client? un port pour x client? (si oui comment choisir ce x?) ou un port pour tous les clients?
J'ai fait quelques recherches, et il semblerait que les n° de ports servent à définir l'application de destination du message pour éviter de "s'embrouiller" mais chaque client aura un processus dédiés au traitement de ses messages.

Ben le mieux selon moi ce serait encore de faire le principe du ssh. Le serveur fork ou ouvre un thread pour chaque client et communique via un autre port. De cette façon tu n'as pas à faire le tri des packets reçus et le port "officiel" sert seulement à l'établissement de la connection. C'est la solution la plus rapide et la moins consommatrice que je connaisse.

3) Pour la communications entre processus, on a les tubes et la mémoire partagée.
Les tubes sembles intéressant pour la discutions de processus 2 à 2 et la mémoire partagée pour la discutions entre un grand nombre de processus.
Mais quels sont les avantages et les défauts de chacun?

Là par contre je comprends pas très bien. Tu parles de quels processus? Ceux des clients et serveurs ou ceux que le serveur va créer? Parce que si tu parles des clients et serveurs oublies les 2 solutions. Si tu parles des processus du serveur, moi je te conseillerai la mémoire partagée et des mutex et sémaphore. Parce que les tubes devronts être lu via un gestionnaire. C'est plus sûre mais c'est plus lent.

4) Pour les tubes, il me semble qu'on fait un fopen("nom", "w") et un fopen("nom", "r") pour le créer mais plus le tube sera utiliser plus il va "grossir", comment faire pour vider le début dont on a pas besoin?
(il faut aussi faire un fopen("nom", "r") après chaque modification il me semble non?)

Non. Pour les tubes tu fais un pipe directement. Mais le tube ne grossit pas! C'est le même système que stdin et stdout. Il n'y a que le buffer interne qui grossira si les infos ne sont pas lues (d'où mon conseille de mémoire partagée) mais lorsqu'elles sont lues, l'espace est libéré.

5) Beaucoup de processus du serveur vont fonctionner par scrutation, c'est assez dommage...
J'ai dans l'idée de leur faire des sleep(x) s'ils se réveillent au bout de x secondes, ils font un "time out"
Et lors de la réception d'un message, un interruption réveille (SIGCONT) le processus concerné qui traitera le message et réveillera les autres processus impliqués. Est-ce une bonne idée?

Pour répondre à çà il faudrait qu'on en sache un peu plus sur les fonctions des processus dont tu parles. Le processus sensé recevoir les données du client un poll() est mieux. Sinon pour les processus interne du serveur un poll sur une socket unix c'est pas mal aussi.

[Neckara]

Question 1:

Si je comprend bien, plutôt qu'établir une socket par demande de vérification de l'accès du serveur, il vaut mieux ne faire qu'une seule socket par client.
Dans ce cas là, il faudra aussi que le client dise qu'il est lui aussi accessible (mais peut être qu'on s'en aperçoit en cas de non-échec de l’envoi d'un paquet du serveur vers le client?)


Question 2:

Donc si je comprend bien je fait un socket par port?
Je vois comment fonctionne le fork et il me paraît plutôt intéressant, ainsi, plutôt que d'écrire plusieurs programmes avec des fonctions différentes, je n'ai qu'à faire des fork et à définir leur rôles en fonctions qu'il soient fils ou qu'ils soient père. wait(null) permet d'attendre la fin du processus fils, mais le père peut très bien se terminer avant le fils sans problèmes non?
L'avantage c'est que cela sera plus rapide que de lancer un programme à chaque nouveau client.


Question 3:

Pour les communications entre processus, je parlais des processus côté serveurs.
Pour le client/serveur, j'utiliserais des socket (on m'a d'ailleurs conseillé openSSL).
Il faudra que je regarde les mutex.

Question 4: j'ai ma réponse merci

Question 5: Le problème avec les socket Unix, c'est qu'ils utilisent un protocole réseau interne donc l'échange de donnée est relativement longue, c'est d'ailleurs pour cela que je pense utiliser la mémoire partagée.

EDIT : je suis bête, je n'ai qu'à lancer des forks pour faire les divers traitements!

Il n'y a donc que pour les entrée des données clients que je devrais faire de la scrutation.
Mais peut-être que la scrutation est négligeable?

[baccali]

Question 1:

Si je comprend bien, plutôt qu'établir une socket par demande de vérification de l'accès du serveur, il vaut mieux ne faire qu'une seule socket par client.
Dans ce cas là, il faudra aussi que le client dise qu'il est lui aussi accessible (mais peut être qu'on s'en aperçoit en cas de non-échec de l’envoi d'un paquet du serveur vers le client?)

Qu'entends-tu par "vérification de l'accès du serveur?". Pour l'accès du serveur, comme je t'ai dit, le mieux c'est de faire un autre processus en UDP qui ne sert qu'à dire "oui le vrai serveur est là!". En UDP pour éviter l'overload du TCP. Un exemple :

_ Tu as le pid 40000 qui attend sur l'adresse UDP 192.168.1.1:54000.
_ Tu as ton vrai serveur (du moins le gestionnaire de connection), pid 41000 qui attend sur l'adresse TCP 192.168.1.1:55000.

Donc au démarrage du serveur tu as déjà 2 processus au minimum.

Question 2:

Donc si je comprend bien je fait un socket par port?
Je vois comment fonctionne le fork et il me paraît plutôt intéressant, ainsi, plutôt que d'écrire plusieurs programmes avec des fonctions différentes, je n'ai qu'à faire des fork et à définir leur rôles en fonctions qu'il soient fils ou qu'ils soient père. wait(null) permet d'attendre la fin du processus fils, mais le père peut très bien se terminer avant le fils sans problèmes non?
L'avantage c'est que cela sera plus rapide que de lancer un programme à chaque nouveau client.

Non, ce n'est pas Windows Sous Linux lorsque le père se termine, sa descendance aussi. Exception faite des fork "détachés" du père. D'ailleurs c'est le processus normal du démarrage d'un serveur. Un serveur commence par se détacher du processus appelant, ferme stdin et stdout et commence ses tâches.

Par contre, pour les processus fils dont je parle, vaut mieux au contraire qu'ils restent attachés au père. Les détacher du père serait se compliquer la vie pour rien. Voici ce à quoi je pense.

Le serveur se lance.
1) Il lance un fork pour le serveur sensé répondre à ceux qui veulent savoir si le serveur est en activité. Ce serveur bind sur l'adresse UDP 192....1 port X et ne fait rien d'autre qu'attendre des requêtes (poll()).
2) Le serveur principal (celui qui a lancé le fork() )bind sur l'adresse TCP 192...1 port Y. il ouvre une zone de mémoire partagée et attend des connections.

Le premier client

1) Le client envoie un paquet en UDP sur le port X (En fait 3 ou 4 au cas où les paquets ce sont juste perdus. C'est de l'UDP)
2) Il reçoit une réponse, ok le serveur est en route. Il le contacte en TCP sur le port Y.
3) Le serveur de jeu reçoit une connection sur le port Y. Il fork.
4) Le fork renseigne les fonctions des signaux et ouvre le port Z. Il rentre en contacte avec le client (A toi de voir les détails) et traite avec le client par ce port.
etc...

Question 3:

Pour les communications entre processus, je parlais des processus côté serveurs.
Pour le client/serveur, j'utiliserais des socket (on m'a d'ailleurs conseillé openSSL).

Pourquoi openSSL? on parle bien d'un serveur de jeux? Nan si tu veux des performances optimales laisses tomber les overloads inutiles.

Il faudra que je regarde les mutex.

Oui renseignes toi bien. Surtout si les 10 joueurs de la même équipe shootent en même temps sur le drapeau ennemis (d'ailleurs je sais pas si ça te parle mais renseignes toi aussi sur les RTS, real-time signals. Ca évitera que tes fils attendent 10 000 ans sur la même ressource.)

Question 5: Le problème avec les socket Unix, c'est qu'ils utilisent un protocole réseau interne donc l'échange de donnée est relativement longue, c'est d'ailleurs pour cela que je pense utiliser la mémoire partagée.

Effectivement!

Moi je pensais plutôt à un truc du genre:

*arrivée d'un message*
→ interruption → réveille le processus impliqué (SIGCONT).

-> Recevoir_client1 se réveille regarde s'il y a un message et traite ce message.
Si il y a pas de message, il en conclu que le client s'est déconnecté, sinon, il réveille les autre processus impliqué et se rendort pour x secondes.
Exemple: il reçoit un message pour le canal de chat ''groupe'' il va transmettre le message à Envoyer_client2 et Envoyer_client3 et va les réveiller avec (SIGCONT)

Ce qui permettrait d'éviter que des processus prennent le CPU pour faire de la scrutation périodique.

Mais peut-être que la scrutation est négligeable?

C'est une façon de voir les choses. Personnellement Les deux seuls problèmes que je vois là dedans c'est :
1) Ce n'est pas vraiment un système real time et il consommera beaucoup plus car avec 10 000 client géré par une seule fonction. Bah y'en a beaucoups qui vont attendre.
2) Si tu veux un jeux en temps réels tes sleeps seront tellement petits qu'ils ne serviront quasiment à rien.

L'avantage de ce que je te propose c'est déjà que ton serveur n'a pas à faire le tri dans les paquets reçus (ce qui prends beaucoup de temps). Vu que chaque fils attend sur un port bien précis et sait que les paquets qu'il reçoit vient de son client.

L'avantage du poll() c'est que le fils n'a pas à se réveiller, c'est le système qui le réveille quand il reçoit un paquet.

Pour gérer les pertes de connexions. Regarde poll(). Le processus n'a pas à réveiller le système, mais le système le réveille et lui dit pourquoi il l'a réveillé. Si c'est parce qu'il y'a eut une perte de connection, le signal te réveille avec l'info POLL_HUP, si c'est parce que le client a envoyé des donnée, tu reçois l'info POLL_MSG etc... Si tu veux aussi surveiller les inactivités, regardes du côté de alarm().

J'espère t'avoir été utile.

Cordialement.

[souviron34]

Note : poll n'est (malheureusement) pas dispo sous Windows....

D'autre part, pour la question no1, pourquoi particulièrement UDP ?

Et pourquoi simplement ne pas utiliser un socket asynchrone ???


Question no2 : cela s'appelle "un service", ce qui est défini (et setté) sur tel ou tel port.

Et, sous unixoides, cela se passe en "forkant" : le serveur "père" attend (en bloquant) sur ce port. Lorsqu'il reçoit une demande de connexion, il se forke, envoie lesocket de communication au client, et repart en attente.

Sous Win, je ne sais pas comment ça marche, mais ça doit être le même principe à part que cela doit créer des threads plutôt qu'un autre process

Il y a tout ce qu'on peut souhaiter dans la rubrique "réseau" ici-même, y compris des exemples de clients/serveurs.

[baccali]

D'autre part, pour la question no1, pourqoi particulièrement UDP ?

Parce que si c'est simplement pour savoir si le serveur est alive pas besoin d'alourdir la conversation avec du TCP. Un peu comme un ping.

Sous windows c'est le même principe sauf qu'au lieu de socket tu attends sur des handles.

Question no2 : cela s'appelle "un service", ce qui est défini (et setté) sur tel ou tel port.

Comment çà?

[Neckara]

Je comprend, un port pour signaler*: le serveur est là en UDP
Un port pour la connexion en TCP
Par contre il faudrait que je recherche les différences entre UDP et TCP mais je pense pouvoir trouver sur le net.

Sous Linux, lorsque le processus père meurt, le processus fils n'est pas adopté par init(1)*?


''Pourquoi openSSL? on parle bien d'un serveur de jeux? Nan si tu veux des performances optimales laisses tomber les overloads inutiles.''

Mais il faut bien que je chiffre les connexions (+hash code etc...) pour avoir un minimum de sécurité non*?

Si je comprend bien, poll() ne demande pas le CPU pour scruter*?

Merci pour vos réponses, je dois juste rechercher les différences TCP/UDP et je pense pouvoir commencer à coder^^

EDIT : c'est bon j'ai trouvé la différence

EDIT2 : le processus fils copie l'environnement du père.
Les pointeurs pointent donc vers la même zone non?
J'ai juste à allouer une zone mémoire et à mettre en place un mutex?

[baccali]

Je comprend, un port pour signaler*: le serveur est là en UDP
Un port pour la connexion en TCP
Par contre il faudrait que je recherche les différences entre UDP et TCP mais je pense pouvoir trouver sur le net.

Te casses pas la tête! Tout ce que tu as besoin de savoir c'est que TCP allourdit les conversations réseau en rajoutant du control pour savoir si tel ou tel packet s'est perdu pendant la conversation. Ce qui n'est pas nécessaire ici. Ici c'est du binaire et il n'y a pas plus court comme conversation : "Je peux? oui/..." (en fait c'est même de l'unaire ). Si tu veux c'est un peu le principe du ping sur un port précis qu'on met en place. Mettre du TCP ici reviendrai un peu à faire : "est-ce que tu es sûr que tu es là parce que le doute m'habite? - Bah écoutes ou je suis là sinon toi çà va? etc..."

Sous Linux, lorsque le processus père meurt, le processus fils n'est pas adopté par init(1)*?

Oui mais pas comme tu le penses. Ce à quoi tu penses c'est le principe de Windows. Sous Linux lorsqu'un processus meurt tous ses fils rentrent dans un état qu'on appelle zombie car ils n'ont plus de père. Le truc c'est qu'ils reçoivent le sigkill, sigterm etc.. en même temps que le père et s'arrêtent donc. Hors lorsqu'un processus se termine avant que Linux libère les ressources un ancêtre doit lire le code retour. Malheureusement le père, ayant reçu le sigkill, n'est plus. Init sert donc à lire le code retour du fils. Mais il ne l'adopte pas pour lui permettre de continuer sans son père.


''Pourquoi openSSL? on parle bien d'un serveur de jeux? Nan si tu veux des performances optimales laisses tomber les overloads inutiles.''

Mais il faut bien que je chiffre les connexions (+hash code etc...) pour avoir un minimum de sécurité non*?

Franchement qui piraterait ce genre de truc? Ce qu'il faut se dire c'est que le cryptage rajoute du travail à ton serveur. Et pas qu'un peu vu qu'on a même dû améliorer le protocole ssl. Maintenant le RSA ne sert qu'à mettre en place une crypto symétrique. Mais la charge de décryptage et de cryptage reste quand même relativement importante. Et lorsqu'il s'agit d'un serveur de jeux, tu dois le savoir, la moindre microseconde perdu est critique. Donc c'est un choix à faire. Mais franchement, qui chercherait à pirater une telle connexion. Pour l'entrée de mot de passe c'est logique mais là...! Si quelqu'un cherche à s'amuser avec la communication il y'a 95% de chance que ce soit pour la bousiller (ce qu'il peut faire avec ou sans crypto) et non retransmettre ta partie sur son écran. Si il veut voir ta partie il a qu'à venir chez toi!

Si je comprend bien, poll() ne demande pas le CPU pour scruter*?

C'est bien çà. Lors d'un sleep, non seulement ton client est obligé d'attendre que ton sleep se réveille mais en plus, vu qu'on est sur un serveur de jeux, ton sleep devra se réveiller pratiquement tout le temps pour ne pas avoir trop de latence côté client. Ce qui, sur 1000 clients, risque de rajouter de la charge plusqu'autre chose. Alors qu'avec un poll() ton processus ne requiert rien du tout, c'est le système qui le réveille quand il y'a de l'activité, avec les infos sur cette activité. Ca évite à ton fils de se réveiller pour rien et de bouffer du CPU pour rien. si tu veux il y'a pause() aussi mais qui marche plutôt avec les signaux.

Bon courage et bon dev Tu as déjà avancé un peu côté client ou tu commences à peine le projet au grand complet?

[Neckara]

J'ai commencé par un offline qui est presque fini, il ne manque que les graphisme ainsi que quelques petites fonctions comme la sauvegarde de la partie etc...

Donc niveau sécurité faut juste que je me fasse un hash code + RSA seulement pour la transmission du mdp/login

[baccali]

nice! Bon courage pour la suite. J'espère juste que l'intégration du jeu en réseau ne t'obligera pas trop à modifier ton client. (ce qui a été mon cas! La jeunesse, c'était il y'a très longtemps et du codage "straight" )

Donc niveau sécurité faut juste que je me fasse un hash code + RSA seulement pour la transmission du mdp/login

C'est un conseil mais effectivement je pense que c'est la meilleure chose à faire.

A++

[souviron34]

Oui mais pas comme tu le penses. Ce à quoi tu penses c'est le principe de Windows. Sous Linux lorsqu'un processus meurt tous ses fils rentrent dans un état qu'on appelle zombie car ils n'ont plus de père. Le truc c'est qu'ils reçoivent le sigkill, sigterm etc.. en même temps que le père et s'arrêtent donc.
Hors lorsqu'un processus se termine avant que Linux libère les ressources un ancêtre doit lire le code retour. Malheureusement le père, ayant reçu le sigkill, n'est plus. Init sert donc à lire le code retour du fils. Mais il ne l'adopte pas pour lui permettre de continuer sans son père.

Euh....
Non..

Si une connexion est ouverte entre un client et un serveur fils, si le père meurt (qu'on le tue ou autre), la connexion reste ouverte avec le fils...

De même, si un binaire est en train de tourner, "mover" ou renommer lefichier ne change rien à l'éxécution en cours..


Le processus devient effectivement "zombie", cela ne l'empêche pas de continuer à fonctionner.. Il appartient désormais à "root", avec un numéro de processus père 0 ou 1. Vu que le socket et la connexion étaenti déjà ouverts, rien ne change..

La seule chose qui change c'est que toute nouvelle demande de connexion se verra refusée au motif "no service".

[baccali]

Euh....
Non..

Si une connexion est ouverte entre un client et un serveur fils, si le père meurt (qu'on le tue ou autre), la connexion reste ouverte avec le fils...

"Euh..." Si! Je sais pas de quel OS tu parles mais lorsque tu fermes ton terminal tous les processus qu'il a lancé meurent. Sauf si le processus est détaché. Pourquoi, parce que sous Linux il y'a le concept de groupe de processus. Lorsque le père ou un fils reçoit un signal, tous les processus du groupe reçoivent ce signal. Donc le sigterm sera reçu par les fils. Alors c'est sûr que si ils sont en plein appels système bloquant ils mettront du temps avant de s'arrêter, mais ils s'arrêteront aussi tôt revenus en user mode. A moins que le signla soit catcheable et qu'ils l'ignore. Malheureusement, lorsque le père meurt à cause d'un SIGTERM, signal non catchable reçu lors d'un segfault, tous ses fils meurent avec lui!

EDIT2 : le processus fils copie l'environnement du père.

Attention quand même car dans le cas d'un fork() cela dépend de l'implémentation et tous les systèmes n'ont pas ce comportement. Certains réinitialise les signaux (dont les BSDlike si je me souviens bien.). C'est pour cela qu'il vaut mieux mettre l'initialisation des signaux APRES avoir forké, dans ton

Code :

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

1
2
3
switch(fork())
       case 0:
              ...

[Neckara]

Je ne parlais pas des signaux, mais d'un pointeur.

Si avant le fork j'ai un pointeur int *test

Après le fork, les deux processus pourront modifier la même variable non?
J'avais lu quelque part de se méfier aussi lors de l'ouverture d'un fichier, le fils peut modifier le curseur de lecture du père me semble.

Sinon, je suis en train de penser, je vais devoir aussi regarder dans une BDD.
Est-ce que les BDD gèrent les correctement les écriture/lecture : ie dans le cas où une écriture et une lecture soit demandée en même temps, qu'il n'y ai pas d'erreur (un peu le même problème que la mémoire partagée en fait).

EDIT : tcp prend en compte les erreurs de transmissions pouvant supprimer/rajouter/complémenter un bit non?

[baccali]

Je ne parlais pas des signaux, mais d'un pointeur.

Si avant le fork j'ai un pointeur int *test

Après le fork, les deux processus pourront modifier la même variable non?
J'avais lu quelque part de se méfier aussi lors de l'ouverture d'un fichier, le fils peut modifier le curseur de lecture du père me semble.

Si ta variable n'est pas dans la mémoire partagée, tu ne modifieras pas la même variable car Linux implémente (depuis le noyau 2.4 je crois) le copy-on-write. Tu as les même infos (valeurs des variables etc..) que ton père (en fait pour être exacte vous lisez encore la même page, le même emplacement mémoire si tu veux, mais lorsque tu modifies une variable Linux en fait une copie dans l'espace mémoire de ton processus. Si c'est vraiment génant regardes plutôt du côté des threads

Sinon, je suis en train de penser, je vais devoir aussi regarder dans une BDD.
Est-ce que les BDD gèrent les correctement les écriture/lecture : ie dans le cas où une écriture et une lecture soit demandée en même temps, qu'il n'y ai pas d'erreur (un peu le même problème que la mémoire partagée en fait).

C'est l'avantage d'une BDD mais si la BDD traite la lecture avant l'écriture tu auras une variable érronées. C'est pour quoi la base de donnée. Vaut mieux marcher avec des sémaphores non? La BDD est vraiment nécessaire? Parce que ça risque de sérieusement ralentir ton système si tu veux l'utiliser dans ce type d'applis.

[Neckara]

Disons que la mémoire partagée c'est de la mémoire vive, mais j'ai tout de même besoin d'une mémoire morte pour stocker les hash des login/mdp, sauvegarder la progression, etc...

[baccali]

Ah oui alors dans ce cas effectivement une solution basée sur une BDD est plutôt logique. Tu n'as pas à t'en faire pour les entrées/sorties. Ca ne devrait pas poser de problèmes. Je pensais que tu voulais les utiliser en live!

[Neckara]

Nan, je ne suis pas fou à ce point.

Puis ça serait assez bête d'utiliser un BDD (= système de fichier) à la place de la mémoire partagée que je veux utiliser car la lecture de fichier n'est pas pratique (donc je projette le fichier sur la mémoire vive -> mémoire partagée).

Je ne me trompe pas? La mémoire partagée est bien un fichier projeté sur la mémoire?

Sinon, le TCP prend-t-il en compte les suppression/ajout/complémentation de bit lors des échanges?

[baccali]

Je ne me trompe pas? La mémoire partagée est bien un fichier projeté sur la mémoire?

Oui c'est bien çà! Tu fais un mmap() en précisant bien que c'est partagé, puis tu passes le fd aux fils (c'est une solution, les IPC system V en sont une autre).

Sinon, le TCP prend-t-il en compte les suppression/ajout/complémentation de bit lors des échanges?

Comment çà?

[Neckara]

On a des mots d'informations : bits contenant le message
Auxquels on rajoute des bits de sur-codage calculé à partir du mot d'information.
On obtient ainsi un mot de code.

Or comme le mot de code est plus long que le mot d'information, il y a donc plus de mots de codes possibles que de mots d'informations possibles.

Pendant la transmission de ces mots de codes, des bits peuvent être supprimé, rajouté, ou être complémenté.

A partir de là, si le mot de code ne correspond pas à un mot d'information existant, on peut le corriger avec une probabilité plutôt importante.

Même si la probabilité d'une erreur est plutôt faible (je ne connais pas le chiffre), cela reste problématique vu qu'il y aura plusieurs clients qui enverront/recevront plusieurs paquets.

Imagine qu'un client fasse un échange, clique sur "annuler" et que le message reçu soit "ok", c'est assez problématique.

[baccali]

SI J'AI BIEN COMPRIS, ce qui t'inquiète c'est que les données soient erronées à l'arrivée sur le serveur?

Si c'est le cas ne t'en fais pas car TCP s'occupe de çà pour toi! C'est justement de çà dont je parlais quand je te disais que TCP rajoute des infos de contrôle à la communication. En fait TCP utilise des hashs, des numéros de packets etc... (je te passe les détails) pour vérifier que l'information arrive à destination en bon état et renvoie les packets manquants ou erronés si nécessaire donc tant que le hash que tu envoies est bon, il sera bon aussi à l'arrivée.

C'est l'avantage d'utiliser TCP plutôt que de l'UDP. Tout ce que tu as à faire c'est écrire des infos correctes dans la socket.