Sehr praktisch in diesem Zusammenhang (falls ich die Problematik verstanden habe), ist ein Workerthread auf Clientseite. Der Workerthread verwaltet eine Liste von Jobs. Jeder Job kümmert sich z.B. um einen
Query/Response-Zyklus per
TCP. Oder verschickt nur die Daten (dann muss die Antwort asynchron dem Job zugeordnet werden).
Im einfachen Fall (also dem synchronen
Query/Response) hast Du einen Timer, der die Alive-Anfragen einfach in die Jobliste einfügt. Wenn Du nun etwas vom Server willst, erzeugst Du einen entsprechenden Job und fügst in auch einfach in die Liste ein. Er wird dann 'schnellstmöglich' abgearbeitet, nämlich entweder sofort (der Workerthread hatte gerade nichts zu tun), oder später (wenn der WT den aktuellen Job gerade abarbeitet), oder noch später (wenn noch andere Jobs in der Warteschlange/Jobliste sind).
Auf jeden Fall wird ja so sichergestellt, das jeder
Query-Response-Zyklus garantiert isoliert abgearbeitet wird und damit sollten deine 'Client-wird-mit-Antworten-zu-vorherigen-Anfragen-verwirrt'-Probleme gelöst sein.
@mkinzler: Was verstehst du unter 'Erreichbarkeit testen'? Nur weil die Connection noch aktiv ist, heißt es ja nicht, das man wirklich eine Verbindung hat. Diese Form des 'Ping', oder 'Alive' mit Sequenzzähler ist immer da extrem wichtig, wo man unbedingt wissen muss, ob die Gegenstelle erreichbar ist. Es wäre auch denkbar, das Client und Server wirklich aus dem Tritt sind (d.h. Frage X wird mit Antwort Y-1 beantwortet). In diesem Fall würde ein Ping zwar sagen 'Alles Roger', aber die Kommunikation ist im Eimer. Eine spezielle 'Alive?'-Anfrage mit Sequenznummer dagegen erkennt zuverlässig, ob die Welt noch in Ordnung ist und trennt die Verbindung ggf. (und baut sie dann wieder auf).