Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que
guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et
30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau
socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de
la couche protocolaire applicative et doit décrypter les infos en temps
réel puis les insérer dans une base de donnée (ces deux infos. sont
importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent:
1) La base de donnée à ses limites quant aux nombre de connexions
simultanées possibles.
2) L'OS et son implémentation de Python (voir un thread sur le Forum
anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000
sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à:
1) La mémoire
2) Le CPU
3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type:
1) Dois-je changer l'heure ?
2) As-tu une mise à jour de mon soft que je dois télécharger ?
3) Es-tu prêt à recevoir mes transactions ?
4) etc ....
_et_ que (les deux infos. préliminaires)
1) Je dois accéder à une base de donnée côté serveur
2) Je dois accéder à un HSM
(http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft.
style Zope ou autre m'aiderait grandement quant à la (désolé pour
l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de
gérer toutes les contraintes décrites ci-dessus ?
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Bonsoir,
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et
30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau
socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de
la couche protocolaire applicative et doit décrypter les infos en temps
réel puis les insérer dans une base de donnée (ces deux infos. sont
importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) :
quel est l'OS sur les terminaux de paiement ?
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
BertrandB
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
Me goure-je ? je pensais que justement le propre des Thread était de partager la mémoire et c'était justement ce qui les distinguait des process qui ne partagent que l'image de l'exécutable ?
Par contre sur AIX3.5 il y avait un écroulement des performances au delà de 1000 process/thread jamais testé mais j'avais du prendre en compte ces recomandation de Bull pour une appli boulot.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
Me goure-je ? je pensais que justement le propre des Thread était de
partager la mémoire et c'était justement ce qui les distinguait des
process qui ne partagent que l'image de l'exécutable ?
Par contre sur AIX3.5 il y avait un écroulement des performances au delà
de 1000 process/thread jamais testé mais j'avais du prendre en compte
ces recomandation de Bull pour une appli boulot.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
Me goure-je ? je pensais que justement le propre des Thread était de partager la mémoire et c'était justement ce qui les distinguait des process qui ne partagent que l'image de l'exécutable ?
Par contre sur AIX3.5 il y avait un écroulement des performances au delà de 1000 process/thread jamais testé mais j'avais du prendre en compte ces recomandation de Bull pour une appli boulot.
hg
jean-michel bain-cornu wrote:
Bonjour,
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Lorsque tu peux coder en python, tu peux peut-être simplement utiliser la BDD pour échanger tes infos entre le client et le serveur : -le client enregistre une requête dans une table -un démon serveur voit la requête et enregistre une réponse -le client voit la réponse. J'utilise ça pour un de mes softs, avec un démon tournant en service windows (merci à py2exe). Comme ça, pas besoin de programmer de socket, c'est déjà tout fait dans le client BDD. Et pas de problème d'engorgement : on pourrait avoir plusieurs serveurs démons si nécessaire, sans paramétrage client supplémentaire. Ceci dit, ça ne résoud pas le pb des TPE... A+ jm
Hélas, je dois garder le même soft. serveur que le client soit codé en Python, C, ASM ....
hg
jean-michel bain-cornu wrote:
Bonjour,
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion
(niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui
se charge de la couche protocolaire applicative et doit décrypter les
infos en temps réel puis les insérer dans une base de donnée (ces deux
infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) :
quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on
passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ...
codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien
sûr.
Lorsque tu peux coder en python, tu peux peut-être simplement utiliser
la BDD pour échanger tes infos entre le client et le serveur :
-le client enregistre une requête dans une table
-un démon serveur voit la requête et enregistre une réponse
-le client voit la réponse.
J'utilise ça pour un de mes softs, avec un démon tournant en service
windows (merci à py2exe). Comme ça, pas besoin de programmer de socket,
c'est déjà tout fait dans le client BDD. Et pas de problème
d'engorgement : on pourrait avoir plusieurs serveurs démons si
nécessaire, sans paramétrage client supplémentaire.
Ceci dit, ça ne résoud pas le pb des TPE...
A+
jm
Hélas, je dois garder le même soft. serveur que le client soit codé en
Python, C, ASM ....
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Lorsque tu peux coder en python, tu peux peut-être simplement utiliser la BDD pour échanger tes infos entre le client et le serveur : -le client enregistre une requête dans une table -un démon serveur voit la requête et enregistre une réponse -le client voit la réponse. J'utilise ça pour un de mes softs, avec un démon tournant en service windows (merci à py2exe). Comme ça, pas besoin de programmer de socket, c'est déjà tout fait dans le client BDD. Et pas de problème d'engorgement : on pourrait avoir plusieurs serveurs démons si nécessaire, sans paramétrage client supplémentaire. Ceci dit, ça ne résoud pas le pb des TPE... A+ jm
Hélas, je dois garder le même soft. serveur que le client soit codé en Python, C, ASM ....
hg
jean-michel bain-cornu
Bonjour,
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Lorsque tu peux coder en python, tu peux peut-être simplement utiliser la BDD pour échanger tes infos entre le client et le serveur : -le client enregistre une requête dans une table -un démon serveur voit la requête et enregistre une réponse -le client voit la réponse. J'utilise ça pour un de mes softs, avec un démon tournant en service windows (merci à py2exe). Comme ça, pas besoin de programmer de socket, c'est déjà tout fait dans le client BDD. Et pas de problème d'engorgement : on pourrait avoir plusieurs serveurs démons si nécessaire, sans paramétrage client supplémentaire. Ceci dit, ça ne résoud pas le pb des TPE... A+ jm
Bonjour,
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion
(niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se
charge de la couche protocolaire applicative et doit décrypter les infos
en temps réel puis les insérer dans une base de donnée (ces deux infos.
sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) :
quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe
du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en
C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Lorsque tu peux coder en python, tu peux peut-être simplement utiliser
la BDD pour échanger tes infos entre le client et le serveur :
-le client enregistre une requête dans une table
-un démon serveur voit la requête et enregistre une réponse
-le client voit la réponse.
J'utilise ça pour un de mes softs, avec un démon tournant en service
windows (merci à py2exe). Comme ça, pas besoin de programmer de socket,
c'est déjà tout fait dans le client BDD. Et pas de problème
d'engorgement : on pourrait avoir plusieurs serveurs démons si
nécessaire, sans paramétrage client supplémentaire.
Ceci dit, ça ne résoud pas le pb des TPE...
A+
jm
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Lorsque tu peux coder en python, tu peux peut-être simplement utiliser la BDD pour échanger tes infos entre le client et le serveur : -le client enregistre une requête dans une table -un démon serveur voit la requête et enregistre une réponse -le client voit la réponse. J'utilise ça pour un de mes softs, avec un démon tournant en service windows (merci à py2exe). Comme ça, pas besoin de programmer de socket, c'est déjà tout fait dans le client BDD. Et pas de problème d'engorgement : on pourrait avoir plusieurs serveurs démons si nécessaire, sans paramétrage client supplémentaire. Ceci dit, ça ne résoud pas le pb des TPE... A+ jm
Laurent Pointal
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
Me goure-je ? je pensais que justement le propre des Thread était de partager la mémoire et c'était justement ce qui les distinguait des process qui ne partagent que l'image de l'exécutable ?
C'est X Mo alloué en plus par thread, dans la mémoire du même processus qui contient ces threads (ie. un thread peut aller manipuler des données dans les Mo d'un autre thread sans problème). Ceci parce que chaque thread a besoin d'un espace pour sa pile.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
Me goure-je ? je pensais que justement le propre des Thread était de
partager la mémoire et c'était justement ce qui les distinguait des
process qui ne partagent que l'image de l'exécutable ?
C'est X Mo alloué en plus par thread, dans la mémoire du même processus
qui contient ces threads (ie. un thread peut aller manipuler des données
dans les Mo d'un autre thread sans problème).
Ceci parce que chaque thread a besoin d'un espace pour sa pile.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
Me goure-je ? je pensais que justement le propre des Thread était de partager la mémoire et c'était justement ce qui les distinguait des process qui ne partagent que l'image de l'exécutable ?
C'est X Mo alloué en plus par thread, dans la mémoire du même processus qui contient ces threads (ie. un thread peut aller manipuler des données dans les Mo d'un autre thread sans problème). Ceci parce que chaque thread a besoin d'un espace pour sa pile.
BertrandB
C'est X Mo alloué en plus par thread, dans la mémoire du même processus qui contient ces threads (ie. un thread peut aller manipuler des données dans les Mo d'un autre thread sans problème). Ceci parce que chaque thread a besoin d'un espace pour sa pile.
Des piles de plusieurs Méga octets ... bon il va falloir que je me
remettes à l'informatique de mon tant c'était quelques kilos.
C'est X Mo alloué en plus par thread, dans la mémoire du même processus
qui contient ces threads (ie. un thread peut aller manipuler des données
dans les Mo d'un autre thread sans problème).
Ceci parce que chaque thread a besoin d'un espace pour sa pile.
Des piles de plusieurs Méga octets ... bon il va falloir que je me
remettes à l'informatique de mon tant c'était quelques kilos.
C'est X Mo alloué en plus par thread, dans la mémoire du même processus qui contient ces threads (ie. un thread peut aller manipuler des données dans les Mo d'un autre thread sans problème). Ceci parce que chaque thread a besoin d'un espace pour sa pile.
Des piles de plusieurs Méga octets ... bon il va falloir que je me
remettes à l'informatique de mon tant c'était quelques kilos.
BertrandB
Des piles de plusieurs Méga octets ... bon il va falloir que je me remettes à l'informatique de mon tant c'était quelques kilos. Et à l'orthographe .... bien sur il fallait lire de mon temps
que je me remette
Des piles de plusieurs Méga octets ... bon il va falloir que je me
remettes à l'informatique de mon tant c'était quelques kilos.
Et à l'orthographe .... bien sur il fallait lire de mon temps
Des piles de plusieurs Méga octets ... bon il va falloir que je me remettes à l'informatique de mon tant c'était quelques kilos. Et à l'orthographe .... bien sur il fallait lire de mon temps
