Gestion des threads de communication TCP/IP

Bonjour à tous,

Définition de l'environnement :
j'ai une application d'impression qui reçoit via TCP/IP des messages provenant d'une autre application (et une seule) pour lui dire ce qu'elle doit imprimer.
Mon application arrive bien à recevoir ces messages TCP/IP et à tous les traiter. J'utilise des composants Indy10 et notamment le composant TidTCPServer.

Jusque là tout va bien, sauf lorsque plusieurs messages arrivent (pour imprimer plusieurs pages) il arrivent que celles çi sortent dans le désordre. (Exemple : Page 1, Page 3 et Page 2).
Ceci est du au fait que pour chaque message TCP/IP reçu, un thread est créé. Pour gérer les exclusions mutuelles, je suis passé par une section critique et donc chaque thread créé est en attente de libération de la section. Et donc c'est le premier qui arrive à la vérouiller qui gagne.

Ma question est : Comment faire pour modifier ce genre de comportement. En gros comment faire pour que les messages reçu par le composant TidTCPServer se dépile dans l'ordre de réception?

J'ai bien essayé de passr par une Fifo et stocker les messages TCP/IP dès le réception et de libérer la section juste derrière, mais le problème persiste.

Avis aux experts threads ou toute bonne ame qui aurait une idée. j'espère que j'aurais été suffisement clair, mais je suis disponible pour plus de précision.
Merci d'avance de vos réponses.

Le protocole TCP, contrairement à UDP garantie l'arrivé des paquets
transmit dans le bonne ordre... j'ai l'impression que de ce coté à tout est beau.

Si tu es certain que tes pages sont transmises dans la bonne séquence...Page1, Page2, Page3...
je vois pas pourquoi tu les recevrais dans la mauvaise séquence....

Je devine que tes pages sont envoyées comme des documents distinc à l'imprimante...
(begindoc...Page1 enddoc)... (begindoc...Page2 enddoc)...
(begindoc...Page3 enddoc)...


Une question comme ca, t'as pensé à regarder les propriétés de l'imprimante?
Dans l'onglet "Advanced" (désolé...ici win2k anglais)
"Print Spooled documents first" doit être coché...sinon... ca peu donner exactement le symptome que tu décris.

C'est ma seule idée pour l'instant....

Merci de ta réponse.

concernant l'ordre d'envoi des différents pages, celui çi est bien respecté. Les pages sont bien envoyées dans l'ordre. J'ai un log dans l'event viewer de Windows qui me permet de l'affirmer.

En fait mon programme reçoit un message TCP/IP avec le nom du document à imprimer, les données à lui associer et l'imprimante sur laquelle il faut imprimer.
C'est là que ça se complique, puisque bien que je reçoit les demandes dans l'ordre, j'ai un thread qui est lancé pour chaque demande. Jusque là tout va bien, sauf que pour éviter que chaque thread accède au même ressources, j'ai verrouillé une partie du code ce qui les met en attente. L'ordonnanceur de Windows bascule d'un thread à l'autre jusqu'à ce que les ressources utilisées par le thread en cours soient libérées et là une nouveau thread peut s'executer, mais pas forcément celui de la 2éme demande d'impression!
Donc il faudrait que je puisse ordonnancer ces threads moi-même...

Je te propose donc de memoriser quelque part
dans une fifo la liste des threads créés.

Lorsqu'un tread sort de son attente,
il pourrait vérifier si c'est bien lui qui
est le prochain dans la fifo, si oui, il fait sont
travail et se retire lui-même de la fifo.

dans le cas contraires, il "dors" jusqu'à ce
qu'il y ait un changement dans la fifo.

Citation:

---

Envoyé par Daminus

:
j'ai une application d'impression qui reçoit via TCP/IP des messages provenant d'une autre application (et une seule) pour lui dire ce qu'elle doit imprimer.

---

bien

Citation:

---

Envoyé par Daminus

:
Ceci est du au fait que pour chaque message TCP/IP reçu, un thread est créé.

---

????????????
normalement un thréad pour chaque connextion,,non??? ou j'ai mal compris???

Très bonne remarques edam. Effectivement, j'étais trop penché sur ce problème pour ne pas voir ce qu'il se passait autour.
Donc ce fameux programme qui m'envoie les demandes d'impressions doit ouvrir une connection par demande d'impression et non garder la connection ouverte. Du coup je me retrouve avec pleins de thread et tout se mélange.
J'ai fait un petit programme de simulation pour simuler le fonctionnement et tout devient plus clair... Je vais donc demander à notre prestataire comment est ce qu'il gère ses connections et qu'il arrête de l'ouvrir et de la fermer.
Je vous tiendrais au courant de l'état d'avancement du sujet.
Encore merci

Ca y est j'ai la confirmation du coté de notre perstataire.
Effectivement, il ouvre une connection TCP/IP à chaque envoi de message, je me retrouve alors avec un thread par message et donc dans l'impossibilité de définir leur ordre d'execution.
Merci à tous de votre aide et à bientôt.