Sehr langen String mit Clientsocket an Serversocket senden..

[AnTiPrimaTe]

Ich hab auch kein Wort über Reihenfolge geschrieben.
Es kann nur passieren, dass zwei abgeschickte Frames
als drei Frames ankommen. Und daher muss man wissen,
wo ein Frame (jetzt eigener Frame, Packet, und nicht TCP)
anfängt und endet. Oder?

[Jens Schumann]

Zitat von AnTiPrimaTe:

Ich hab auch kein Wort über Reihenfolge geschrieben.
Es kann nur passieren, dass zwei abgeschickte Frames
als drei Frames ankommen. Und daher muss man wissen,
wo ein Frame (jetzt eigener Frame, Packet, und nicht TCP)
anfängt und endet. Oder?

Nein muss man nicht wissen. Auch wenn anstatt 2 Frames 100 Frames ankommen.
Das ist völlig egal. Weil anschließend alles korrekt über TWinSocketStream
eingelesen wurde. Das ist auch der Grund weshalb ich hier immer und immer wieder
auf TWinSocketStream und blockierende Verbindungen hinweise.

[AnTiPrimaTe]

Aus dem ganzen sieht man, dass Du noch nie richtig mit Sockets
gearbeitet hast, daher fehlt Dir auch das Verständis für
solche Sachen. Ich schreibe seit Jahren Applikationen,
die mehrere Tausenden von Datenframes innerhalb weniger Sekunden verschicken
und weiß wovon ich rede.
Mit der Zeit wirst Du das schon verstehen.

[AnTiPrimaTe]

Beispiel
---------
Man verschickt zwei Kontakte über TCP/IP:

Max,Muster,Neuer Weg 12

und

Eva,Braun,Sternstrasse 14

beide Kontakte müssen z.B. in eine Datenbank abgespeichert werden.

Daten, die ankommen sehe wie folgt aus:

Max,Muster,Neuer Weg 12Eva,Braun,Sternstrasse 14

Wie machst Du das, wenn Du nicht weiß, wo ein Kontakt
anfängt und wo der endet?

Wenn Du aber:
<start>Max,Muster,Neuer Weg 12<end>
<start>Eva,Braun,Sternstrasse 14<end>
verschickst. kannst Du nach <start> und <end> parsen.

Nicht wahr?

[Jens Schumann]

Zitat von AnTiPrimaTe:

Beispiel
---------
Man verschickt zwei Kontakte über TCP/IP:

Max,Muster,Neuer Weg 12

und

Eva,Braun,Sternstrasse 14

beide Kontakte müssen z.B. in eine Datenbank abgespeichert werden.

Daten, die ankommen sehe wie folgt aus:

Max,Muster,Neuer Weg 12Eva,Braun,Sternstrasse 14

Wie machst Du das, wenn Du nicht weiß, wo ein Kontakt
anfängt und wo der endet?

Wenn Du aber:
<start>Max,Muster,Neuer Weg 12<end>
<start>Eva,Braun,Sternstrasse 14<end>
verschickst. kannst Du nach <start> und <end> parsen.

Nicht wahr?

Nein, so würde ich das nicht machen.
Ich hätte da für foldgenden Record in einer unit, die Client und Server verwenden:

Delphi-Quellcode:

  TKontakt = Record
             Vorname   : String[20];
             Nachname  : String[25];
             Strasse   : String[40];
             end;

Diesen Record würde ich auf der Clientseite entsprechend füllen.
Wenn ich z.B. 5 Kontakte versenden möchte, würde ich die Kontakte in einem
TMemoryStream sammeln. Die Kontakte werden dann über TWinSocketStream.CopyFrom(MemoryStream,0)
zum Server befördert. Auf der Serverseite wird innerhalb die Repeat-Schleife der Inhalt
der Verbindung über TWinsocketStream eingelesen (Siehe oben).
Ob Du es glaubst oder nicht. Die einzelnen Kontakte stehen dann alle korrekt in FStream (siehe oben).
Jetzt kann ich mit FStream.Read(aKontakt,SizeOf(TKontakt)) die einzelnen Kontake aus dem Stream lesen und in die Datenbank schieben.

Evt. reden wir ja von unterschiedlichen Dingen

[Jens Schumann]

Hallo AnTiPrimaTe,
ich habe gerade etwas ausprobiert. Meine Testanwendung sendet
zweimal unmittelbar hintereinander (ohne Sleep oder sowas) 100 Kb über TWinSocketStream an
den Server. Die erste Sendung wird in Memo1 und die zweite Sendung in Memo2
angezeigt. Das erreiche ich dadurch, dass ich einen CommandRecord vor
die Nutzdaten in den Stream schreibe (siehe oben).

Kein Problem - klappt prima -

P.S. Jetzt muss ich erstmal ne Runde Mountain-Bike fahren. Ich finde die Diskussion hoch interessant.
Sollten wir fortführen.

[AnTiPrimaTe]

Zitat:

Jetzt kann ich mit FStream.Read(aKontakt,SizeOf(TKontakt)) die einzelnen Kontake aus dem Stream lesen und in die Datenbank schieben.

Und wann willst Du damit anfangen? Angenommen, der Client weiß nicht wie viele
Kontakte übertragen werden. Angenommen die Kontakte kommen in zufälligen
Intervallen und zufälligen Mengen an. Sobald ein Kontakt ankommt, muss der in die DB.
Wenn die Daten ungünstig fragmentiert werden, kann es passieren, dass nur die hälfte
vom Record da ist (die andere kommt mit einer Verzögerung an).
Wenn man in so einem Moment FStream.Read(aKontakt,SizeOf(TKontakt)) macht,
fällt der Client auf die Schnauze ... also muss man warten, bis ein Record komplett da ist.
Wie willst Du das feststellen ohne Signaturen? try ... except?
Server und Client müssen ja gleichzeitig laufen und asynchron, das ist das Problem.
Der Server schickt seine Sachen ab und der Client weiß nicht was auf den zukommt,
das muss der selbst rausfinden, ob ein Kontakt da ist oder zwei und ob die komplett
angekommen sind.

[Jens Schumann]

Hallo,
ich glaube Du überliest geflissendlich das ich von blockierenden Verbindungen schreibe.
Genau Dein Problem lässt damit bestens lösen.
Wenn der Client nicht weiß wieviel Kontakte kommen schickt er eben jeden Kontakt einzeln ab.
Ich habe es mit meinem Testprogramm gestestet was passiert wenn der Client ständig und unmittelbar hintereinander 100 kB Text an den Server sendet. Ich glaube das entspricht ungefähr Deiner Anforderung. Beim Server kommt immer alls korrekt an.

Ich versuch mal zu beschreiben wie Client und Server arbeiten.
- Beide arbeiten mit einer blockierenden Verbindung
- Der Client sendet mit TWinSocketStream seine Daten an den Server. Nachdem der Client seine Daten versandt hat schließt er die Verbindung.
- TServerSocket nimmt den Verbindungsversuch an und erstellt in OnGetThread für die Verbindung einen
TServerClientThread (hier wird ein neuer Thread erzeugt !!!). Der TServerClientThread liest die Daten aus der Verbindung innerhalb von ClientExecute. Wenn alle Daten aus der Verbindung gelesen wurden können die Daten in die Datenbank geschrieben werden. Da ja jetzt alle Daten komplett da sind.

Was kann passieren: Der Client sendet einen Kontakt an den Server während der Server den
vorherigen Kontakt in die Datenbank schreibt. Kein Problem - TServerSocket nimmt den
Verbindungsversuch an und spaltet in OnGetThread einen neuen Thread für die Verbindung ab.

Ich habe mal mein Testprogramm angehängt. Über den Öffnen Button im Client kannst Du eine
Textdatei in das Memo laden. Wenn Du auf Senden klickst sendet der Client zehnmal
das Memo an der Server. Direkt hintereinander !!! Auf dem Server-Formular sind zwei Memos.
Der Inhalt aus dem Client-Memo wird dabei abwechselnd einmal im linken und einmal im rechten
Memo angezeigt.


P.S. als ich noch asynchrone Verbindungen verwendet habe bin ich immer auf das gleiche Problem wie Du gestoßen. Deshalb bin dann zu den komplizierten blockierenden Verbindungen übergegangen.
Asynchrone Verbindungen sind eine MS Erfindnung. Unter Unix gibt es grundsätzlich nur blockierende
Verbindungen. Warum wohl?

[AnTiPrimaTe]

Zitat:

- Der Client sendet mit TWinSocketStream seine Daten an den Server. Nachdem der Client seine Daten versandt hat schließt er die Verbindung.

Das war das fehlende Glied! Habe ich tatsächlich überlesen.

Code:

 until not aWSStream.WaitForData(2000)

Was ist wenn Verzögerung > 2000 ist und nicht alle Daten angekommen sind?
Ach klar, der Thread läuft ja solange der Client da ist ...

Aber jedes man eine neue Verbindung aufzumachen
ist ja auch nicht die schnellste Lösung, gibs doch zu
Zu blocked Sockets habe ich aber ehrlich gesagt selbst irgendwann gewechselt,
weil das sowieso viel besser ist, solche Sachen in einem Thread zu erledigen
und dann mit Messages (oder anderes) an den Main zu schmeißen.

[Jens Schumann]

Hallo AnTiPrimaTe,
gemäß OH soll die Eigenschaft ClientSocket von TServerClientThread den Endpunkt
auf der Serverseite mit dem Client repräsentieren. Seltsamerweise habe ich es noch nicht
geschafft über ClientSocket etwas an den Client zu senden.
Weißt Du wie das geht ?

Bislang habe ich mir damit beholfen, dass auf dem Clientformular ebenfalls eine
TServerSocketkomponente sitzt. D.h Client und Server sind austauschbar. Wenn der Client
Daten sendet ist der Client der Client und der Server der Server. Wenn der Server Daten zum
Client sendet ist der Server der Client und der Client der Server. Funktioniert sehr gut.
Ich finde es aber ziemlich umständlich.