Server schickt dem Client was, Client kann dem Server antworten. Das ist das Grundprinzip
Das ist ein Protokoll das nicht so ganz zu HTTP (siehe Vorschlag weiter vorher) passt. Der Client muss hier nun warten, bis Daten vom Server kommen, diese verarbeiten, und dann wieder warten. (und eventuell eine Antwort zurücksenden).
Dieses Kommunikationsmuster habe ich mit
Indy mal in in einem kleinen Demoprogramm als 'umgekehrte request-response' (Anfrage/Antwort) umgesetzt.
https://mikejustin.wordpress.com/202...ocket-library/, Code ist auf
https://github.com/michaelJustin/ind...equestResponse
Die Oberfläche erlaubt wahlweise, dass der Client eine Anfrage an den Server sendet, oder umgekehrt, der Server eine Anfrage an den Client sendet.
Es fehlt zwar etwas Fehlerbehandlung - zum Beispiel Prüfung auf ReadLnTimeout nach Readln - aber es zeigt, dass auch der Server die erste(n) Nachricht(en) senden kann, nachdem die Verbindung hergestellt ist.
Der clientseitige Code läuft in einem Thread und sein Betriebsmodus wird durch ein Flag gesteuert. Entweder wird ein Request gesendet und dann auf die Antwort gewartet, oder auf einen Request gewartet und eine Antwort gesendet.
Delphi-Quellcode:
while not Terminated do
begin
if Send then
begin
// send request to server and receive response
Send := False;
Request := 'REQ:' + FClientRequestHolder.Text;
TCPClient.IOHandler.WriteLn(Request);
repeat
Response := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
until Response <> '';
LogInMainThread(Request, Response);
end
else
begin
// receive request from server and send response
Request := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
if StartsStr('REQ:', Request) then
begin
Response := 'from client ' + ReverseString(Request);
TCPClient.IOHandler.WriteLn(Response);
end;
end;
end;
An diesem Beispiel fällt die Abwesenheit von CheckForDataOnSource auf. Dieses wird nicht benötigt, da ReadLn solange wartet, bis eine Zeile aus dem Socket gelesen wurde, oder es zu einem Timeout kommt.