Bonjour,
 
je travaille en ce moment sur ma propre implémentation d'un couple de programmes (client et serveur), en python 2.X sous linux, mais mes questions sont assez générales et pas tellement liées au dit environnement, supportant un protocole avec les particularités suivantes:
-1 unique connection par couple machine. Le couple de machine est constitué d'un client (port variable) et d'un serveur (port fixe), en TCP, avec
-Par contre, envoi de messages dans les 2 sens, chacun contenant un numéro de séquence.
-Chaque message est acquitté par une réponse, contenant notamment le numéro de séquence appelant
-Les messages envoyés par le client (hors réponses) sont envoyés à un rythme maximum de N (disons 10 pour commencer) messages par seconde glissante. Si plus de W (disons 4 pour commencer) messages ne sont pas acquittés,
le client doit cesser les envois de message en attendant que le serveur acquitte au moins 1 message.  
 
Au niveau de l'implémentation, le processus "serveur" fork à chaque connection d'un client. Ca ne devrait pas poser de problèmes majeurs pour le moment,
même si un pool de processus gérant chacun un pool de connections, sur le modèle de ce que fait par exemple apache sera plus avantageux pour gérer beaucoup de connections.
 
Je me pose les questions suivantes:
 
-En ce qui concerne la réception des messages dans le programme serveur (après donc la connection et le fork initial), j'hésite entre 2 solutions: utiliser un seul thread et des sockets non bloquantes ou utiliser des sockets bloquantes mais avec 2 thread.
 
Implementation #1

Implementation #2

       
Ma première question est: quelle est l'implémentation à privilégier (socket bloquante + thread OU socket non bloquante)?
 
Ma deuxième question est: y a t il une meilleure solution que d'effectuer un sleep/usleep quand on dépasse le throttling_rate (système d'attente active)?  
 
En effet pour un throttling rate de 20, je dois faire des sleep de moins de 50 ms, mais en cas de charge élevée sur le serveur, je n'ai pas vraiment
de garantie que le sleep ne va pas durer sensiblement plus longtemps que prévu.

Personne?

Peut être en déplaçant le topic dans la catégorie Python ?