Wo im Client auf Nachrichten vom Server warten?

[QuickAndDirty]

Vielleicht sollte ich das als eigens Thema eröffnen, aber :
Ist es möglich einen TIDTcpClient an einen ReadThread und an einen WriteThread zu übergeben und Kontinuierlich zu senden und gleichzeitig zu lesen?
Also NICHT abwechselnd:

Code:

ping pong ping pong ping pong

sondern parallel

Code:

Thread1: ping ping ping ping ping ping 
thread2:      pong pong pong pong pong pong

[jaenicke]

Grundsätzlich kannst du bei Indy zwei Threads verwenden, aber du kannst nicht genau parallel senden und empfangen. Diese Vorgänge selbst musst du z.B. mit TMonitor absichern.

Wenn du wirklich genau parallel senden und empfangen möchtest, empfehle ich ICS. Das funktioniert mit nicht-blockierenden Sockets und asynchronem I/O, ist aber nicht komplett threadsicher. Das bedeutet, soweit ich es verstanden habe, dass du bei TWSocket gleichzeitig in einem Thread SendStr und in einem ReceiveStr nutzen kannst, aber nicht mehrfach die gleiche Operation parallel.

[QuickAndDirty]

Ich bin so ein bisschen auf Indy eingeschossen.
Sprich... ich habe hier nen haufen Code für Indy geschrieben...
Also kann ein Lese-thread und ein Schreib-Thread in einem Indy-TCPClient nicht wirklich zeitgleich lesen und schreiben, sondern eben nur entweder oder?
Also muss ich das Scheduling mit Sleep(1) anstupsen und timeperiodBegin auf 1ms runtersetzen und kleinere chunks lesen /schreiben , damit es sich "kontinuierlich" anfühlt, während ich mit Tmonitor absicher das niemals lesen und schrieben gleichzeitig in einem Client stadtfinden?

Es ist quasi das selben wie mit einem einzige thread in dem abwechselnd gelesen und geschrieben wird in einer Terminate-Schleife?

[jaenicke]

Zitat von QuickAndDirty:

Es ist quasi das selben wie mit einem einzige thread in dem abwechselnd gelesen und geschrieben wird in einer Terminate-Schleife?

Solange du in dem Thread nicht auf die nächsten Daten wartest, sondern immer nur schaust, ob etwas da ist und sonst ggf. schreibst, ist das am Ende das Gleiche, ja.

ICS hat noch andere Vorteile, unter anderem dass eine aktuelle OpenSSL-Version verwendet wird.

[mjustin]

Zitat von QuickAndDirty:

Ich bin so ein bisschen auf Indy eingeschossen.
Sprich... ich habe hier nen haufen Code für Indy geschrieben...
Also kann ein Lese-thread und ein Schreib-Thread in einem Indy-TCPClient nicht wirklich zeitgleich lesen und schreiben, sondern eben nur entweder oder?

Lesen in Thread A und Schreiben in Thread B auf der gleichen TIdTCPClient-Instanz ist threadsafe möglich. Ein einfaches Beispiel in Indy ist die TIdTelnet-Komponente.
Sie liest aus derselben Connection in einem separaten Thread eingehende Nachrichten vom Telnet-Server, und und im Hauptthread schreibt sie ausgehende Nachrichten an ihn.
Das geht natürlich nur, wenn das Protokoll nicht auf Request/Response basiert. Telnet ist nicht Request/Response-basiert.

[Mavarik]

Gleichzeitig senden und empfangen?
Aber nicht zum gleich Ziel, oder?
Das klingt mir nach 2 Verbindungen.

Wenn es das selbe Ziel ist - kann das den der Server?

Ein bisschen mehr Background könnte helfen.

Mavarik

[QuickAndDirty]

Ich mein TCP handelt doch immer einen Port for die eine richtung und einen für die andere, das richtung aus oder?
Also müsste ich doch einen Empfangsthread

Delphi-Quellcode:

  If Client.IOHandler.InputBufferIsEmpty then
  Begin
    Client.IOHandler.CheckForDataOnSource(1000);// vielleicht nur 10 ms pro durchlauf?
    Client.IOHandler.CheckForDisconnect(False);
    if Client.IOHandler.InputBufferIsEmpty then
      Exit;
  end;

  var IDbytes:TidBytes;
  Client.IOHandler.InputBuffer.ExtractToBytes( IDbytes );

und einen Sendethread betreiben können.

[Mavarik]

Naja ich frag nochmal:

Was willst Du erreichen?

[QuickAndDirty]

Das ist in etwas die Architektur

Code:

Legende:
Client -> Server
Server <- Client

Achritektur:
Peer/TCPClient  -> RelayServer <- RelayClient -> Server/TCPServer

Peer sendet Kontinuirlich Messages in "TCP+Proprietär" oder HTTP-SOAP je nach setup.
Peer erwartet Antworten.
Es geht mit um den RelayClient, er muss kontinuirlich TCP traffic egal wie er geformt ist in beide Richtungen in verarbeiteter Form durchleiten.
Verarbeitung ist notwendig da Peer-Informationen an den Daten hängen die von RelayServer an RelayClient gehen und wieder zurück.
Ich arbeite gerade am RelayClient.