Donc, un autre jour de débogage et enfin j'ai une explication.
1) Les SAEAS ne tiraient pas l'événement terminé car ils n'ont pas pu en envoyer plus. Ceci est révélé par Wireshark dû à la vidange de la fenêtre TCP. (TCP Zerowindow)
2) La fenêtre TCP se vidait parce que la couche de mise en réseau passait un événement dans la pile qui a mis trop de temps à terminer, c'est-à-dire qu'il n'y a pas de producteur / consommateur entre la couche réseau et l'interface utilisateur. Ainsi, le réseau OP devrait attendre le dessin de l'écran avant d'envoyer l'ACK.
3) L'événement qui a pris trop de temps était un tirage au sort dans un gestionnaire d'événements sur l'interface graphique. La plate-forme d'essai était une fenêtre de console (qui résumait les messages entrants), c'est pourquoi il n'a pas causé de problème à une charge beaucoup plus élevée. Il est normal de ne pas redessiner l'écran sur chaque message, mais cela se produisait parce que le projet n'est pas encore terminé. Le taux de réadaptation aurait été fixé plus tard.
4) La solution à court terme consiste simplement à s'assurer qu'il n'y a pas de GUIS qui maintient le spectacle. Une solution plus robuste pourrait être de créer un producteur / consommateur sur la couche réseau.