Est-ce judicieux d'utiliser les threads?

Bonjour,

Je fait un programme qui est essentiellement un serveur qui fournit des numéros de série à des IP bien spécifiques qui en font la requête (ces IP sont eux même des serveurs comportant des utilisateurs à qui l'on assigne des numéros de série, et authentifie aussi les utilisateurs ayant DÉJÀ des # de série).

Il y a un thread de génération de numéros, un thread d'evoi/réception et un thread de communication avec une base de donnée mysql.

Pour la génération des numéros, j'utilise un thread qui remplit 2 tableaux de 1024 uint64. Lorsqu'un de ces tableaux est complètement épuisé (i.e. le thread d'envoi a envoyé tt les numéros dans le tableau #1), ce thread rempli de nouveau le tableau avec des nouvelles valeurs, et pendant ce temps, le thread d'envoi a pris le tableau #2 (qui lui est rempli) et l'utilise jusqu'à ce qui soit vide, puis quand cela se produira il retombera sur le #1 et ainsi de suite.
Le tout se fait avec un mutex... le thread d'envoi débloque le thread de génération quand un tableau est vide, etc... Le thread de génération doit aussi s'occuper de faire un "backup" dans la base MySQL et sur un fihier local aussi.

Le thread de communication s'occupe de vérifier les numéros (ont-ils déjà été générés?, puisque chaque doit être unique). Comme chaque numéro généré est stocké dans la base de donnée, un numéro n'étant pas dans la base de donné est "illégal" (le serveur s'occupe de fournir des numéros de série, mais également de s'assurer de l'authenticité des numéros).

Ma question est... est-ce bien d'utiliser autant de threads? Vous voyez je craint que la communication avec la base MySQL ralentisse le tout, puisque quand on authentifie un numéro, on doit attendre la réponse de la fonction SQL (à noter: c'est du théorique enore, aucun code n'est fait pour l'instant).

J'ai peur de diviser inutilement le cache du CPU si je fais trop de threads (comme on dit en anglais, du "false sharing").

Merci,
Array

P.S. J'utilise pthread

Quelqu'un a-t-il une idée de quoi je parle? suggestions?

Bonjour,

Je ne comprend pas l'utilité de l'utilisation de la base de données pour stocker tous les numéros de série. Pourquoi ne pas les stocker en RAM (ou te servir de la RAM comme cache de la base de données) ? Ceci serait plus rapide et te supprimerais un thread.

Pour le thread de génération, j'ai aussi du mal à voir son utilité : générer un numéro de série est-il si coûteux que cela?

Bonjour, et merci bcp pour votre réponse.
Le truc, c'est que le générateur de numéros utilise un algorithme dérivé des "galois linear shift registers" pour générer un numéro *unique*. Pour des raisons qui sont difficiles à expliquer, le numéro doit être petit, quelques charactères seulement... en prenant 62 charactères, soit les nombres, la lettres majuscules et minuscules, je peux représenter jusqu'à 62^6, autours de 56 milliards (changement de base, en base 62 bien évidemment, par exemple Ab72 donne un nombre etc etc). Je ne peux donc pas générer des numéros de série comme certains logiciels le font, par exemple 7A78-787A-902A-82928384 ...

Il faut néanmoins savoir, lorsqu'on authentifie des utilisateurs ayant déjà un numéro de série (comme je l'ai dit le programme en fournit, mais également il s'assure de la légitimité d'un numéro de série existant), si celui-ci a déjà été généré par le passé (dans ce cas cela veut simplement dire que le numéro est légitime)... Come après un moi le programme aura facilement généré plusieurs centaines de milliers de numéros, il faut les garder en mémoire... d'où la banque de données.

Pour le thread de génération, je ne sais pas moi-même. La routine est plutôt rapide oui (générer un million de numéros prend quelques milisecs seulement).

Bonjour,

Il manque une information cruciale : quelle est la volumetrie de la demande ?

Si tu as une demande toutes les minutes, un programme mono-threade n'est pas forcement une betise. Si tu as plusieurs demandes par seconde, ca peut valoir le coup.

Bonjour,

Ne serait-il pas plus simple de montrer l'authenticité d'un numéro de série par calcul ?
Exemple : les deux derniers numéros sont la somme des précédents chiffres modulo 62².
Tu peux aussi utiliser un compteur que tu incrémentes à chaque nouveau numéro généré et que tu chiffres pour générer une partie de ton numéro final.
Tu n'auras plus qu'à le déchiffrer pour retrouver l'ancienne valeur du compteur.

Pour le thread de générations, il lui faut quelques milisecs pour générer un million de numéros, combien de temps faut-il pour utiliser ces millions de numéros?

@Neckara : En fait, le problème, c'est que de 1, la séquence doit absolument être indéchiffrable et de 2, l'algorithme doit garantir à 100% que chaque numéro généré soit unique i.e. qu'il soit généré une seule fois.

@Gangsoleil: Je dirais autor de 50-60 requêtes par seconde lors d'un traffic très agité (assez rare mais peut arriver), et dans les moment plus courant, peut être disons 10-15 requêtes par seconde.

Merci! Vraiment apprécié.

Salut,

Citation:

---

est-ce bien d'utiliser autant de threads?

---

Si on parle d'une application qui supportera une certaine charge: oui. Si c'est bien implémenté ça sera avantageux.
Si tu n'aura pas beaucoup de charge, tu complexifies ton code pour rien.

Citation:

---

J'ai peur de diviser inutilement le cache du CPU si je fais trop de threads

---

3 threads c'est vraiment pas beaucoup.

Citation:

---

Vous voyez je craint que la communication avec la base MySQL ralentisse le tout, puisque quand on authentifie un numéro, on doit attendre la réponse de la fonction SQL

---

C'est un risque effectivement. Mais avec vu les explications que tu donnes, tu n'as pas trop le choix. Pour minimiser ce risque avant de développer l'appli, je ferais des tests de charge sur une maquette (avec un corpus représentatif, pas un exemple jouet) pour estimer le coût de cette com. Si les résultats ne sont pas concluant sur un point ou un autre, tu pourras toujours trouver une autre solution ou des façon d'optimiser avant de devoir modifier du code que tu viens d'écrire ;).
Je ne connais pas trop MySQL, mais il doit y avoir un moyen d'indexer tes tables. Tu peux aussi jouer sur la redondance des données. Par exemple, si tu sais que les requêtes porterons à 80% sur les numéros attribués dans les 30 derniers jours, tu peux faire une vue qui contient les numéros des 30 derniers jours. Tu cherches en premier dans la vue que tu gardes en cache et 80% du temps tu sera gagnant.
De toute façon, l'optimisation prématurée n'est jamais bonne. S'il le faut, ton bottleneck sera ailleurs.
Je pense qu'avant de choisir une solution, il faut prendre conscience de l'ampleur du problème en faisant quelques tests sur MySql, mais aussi sur les autres points qui pourrait être problématiques. Comme par exemple, la génération des numéros.

Citation:

---

Envoyé par Array

@Neckara : En fait, le problème, c'est que de 1, la séquence doit absolument être indéchiffrable et de 2, l'algorithme doit garantir à 100% que chaque numéro généré soit unique i.e. qu'il soit généré une seule fois.

---

Si tu chiffres ton compteur, tu es sûr d'avoir un numéro unique.
Avec un système signature RSA, personne ne devrait pouvoir générer de clés mais tout le monde pourra vérifier la validité des clés (peut éviter des arnaques de fausses clés par exemple).
Tu as au total 372 bits, je pense que c'est suffisant pour avoir une bonne sécurité (?)

Sinon tu n'as pas 62^6 possibilités mais 6^62 soit 10^48 possibilités.
Avec 62^6 possibilités toute protection n'aurais servit à rien car avec de la brute-force on retrouve facilement des clés déjà attribuée.

Neckara, cela semble une possibilité intéressante sauf que 372 bits, c'est trop.
Je dois limiter le plus possible le nombre de caractères (du à des limitations extérieures dont je ne souhaite pas parler, mais qui sont véritablement présentes).

Il fautdrait donc réduire autour de 62^16... Peut tu m'en parler plus, de cette méthode? Quant à aux attaques brute force, on ne parle pas vraiment ici d'un système de clés pour l'activation de logiciels... l'attaque brute-force serait difficile parce que pour valider une clé il faut se connecter à un serveur à chaque fois (le serveur valide ensuite la clé et déconnecte dans le cas d'une clé illégale). Cela prendrait beaucoup beaucoup de temps pour faire du brute force, parce que la connection préalable prend autor de 0.5 à 1 seconde...

Mais je suis néanmoins intéressé par une clé dont il est possible de valider sans nécessiter une base de donnée, en autant que les numéros générés soient uniques (qu'ils ne reviennent pas 2 fois).

Citation:

---

Envoyé par Array

Il fautdrait donc réduire autour de 62^16... Peut tu m'en parler plus, de cette méthode? Quant à aux attaques brute force, on ne parle pas vraiment ici d'un système de clés pour l'activation de logiciels... l'attaque brute-force serait difficile parce que pour valider une clé il faut se connecter à un serveur à chaque fois (le serveur valide ensuite la clé et déconnecte dans le cas d'une clé illégale). Cela prendrait beaucoup beaucoup de temps pour faire du brute force, parce que la connection préalable prend autor de 0.5 à 1 seconde...

---

Si on prend un hackeur ayant 1 000 ordinateurs infectés (c'est relativement peu), il lui faudra 15 778 heures pour trouver une clé si tu n'en as qu'une.
Si tu as 1 000 clés, cela lui prendra moins de 16 heures.

Citation:

---

Envoyé par Array

Mais je suis néanmoins intéressé par une clé dont il est possible de valider sans nécessiter une base de donnée, en autant que les numéros générés soient uniques (qu'ils ne reviennent pas 2 fois).

---

Avec si peut de bits, tu ne peux pas faire grand chose.
Pourquoi ne pas proposer un "fichier de licence" ?
Tu aurais ainsi beaucoup plus de possibilités pour sécuriser.
Sinon RSA doit pouvoir fonctionné de manière sûre avec aussi peu de bits si tu ne distribue pas les clés publiques et que tu les gardes privées.