ClientSocket steam verschicken mit vorherigen Zeichen

[gandime]

Hi,
ich möchte einen Stream verschicken:

Delphi-Quellcode:

var
  cs: TClientSocket;
  FStream:TFileStream;
begin
  cs.Socket.SendStream(FStream);
end;

wie kann ich jetzt hier

Delphi-Quellcode:

procedure TForm1.csWrite(Sender: TObject; Socket: TCustomWinSocket);
begin

end;

bevor das erste Stück des Stream verschickt wird Zeichen hinzufügen
also z.B. 'File-000001:' und im Anschluss dann das Stück vom Stream?

und eine Weitere frage: wie kann man bei der csWrite Procedure herausfinden um welchen Stream es sich handelt, wenn man mehrere gleichzeitig verschickt?

mfg
gandime

[Muetze1]

Tipp: Stell dich doch mal mit einem Brechpunkt in die csWrite Methode rein und schau überhaupt erstmal, ob diese Methode überhaupt aufgerufen wird. Afair nicht.

[gandime]

ok sry das ist mir auch gerade aufgefallen...
ich hab mir jetzt mal die buffergröße rausgesucht die bei sendstream benutzt wurde:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Fstream:TFileStream;
  Buffer: array[0..4095] of Byte;
begin
  Fstream:=TFileStream.Create('D:\a.mp3', fmOpenRead or fmShareDenyWrite);
  Fstream.read(Buffer,sizeof(Buffer));
  cs.Socket.SendBuf(Buffer,sizeof(Buffer));

aber die Server Procedure ClientRead wird erst bei dem zweiten mal drücken ausgeführt!
Jetzt sind meine Bedenken das wenn mehrere dateien gleichzeitig geschickt werden das diese durcheinander kommen können.
Deshalb die Frage ob die ClientRead Procedure zweimal ausgelöst wird oder die Daten einfach hintereinander in einem ankommen?
Deses passiert ja nur da die Daten erst verschickt werden wenn genug vorhanden sind oder wenn eine gewisse Zeit vergangen ist

[Muetze1]

Wenn du zweimal nacheinander SendStream aufrufst, dann kommen die Daten von den jeweiligen Streams in vielen unterschiedlichen Größen und Aufrufen bei deinem ClientRead an - aber in der gleichen Reihenfolge und somit nacheinander folgend. Somit kannst du mit einem OnClientRead das Ende von dem ersten Stream zusammen mit dem Anfang des zweiten Streams empfangen.

Nur damit es später wieder darauf hinausläuft: Dein OnClientRead wird so oft aufgerufen, wie Daten empfangen wurden. Die Teilung dieser Aufrufe und der schon empfangenen Datentypen sind zufällig und entsprechen nicht der Teilung beim Aufruf zum Versenden. Sprich: Wenn du mit SendStream oder SendText irgendwas losschickst, dann ist nicht mal ansatzweise gesagt, dass du diesen als einen Block im OnClientRead wieder empfängst. Somit: Du kannst mehrfach im OnClientRead aufgerufen werden, bis du den gesendeten Text bzw. Daten wieder in einem Stück zusammen hast.

[d1ng0d0gt0r]

Das ganze soll ja eigendlich so von Statten gehen:

Ich lese die Daten beim Client ein wie es gandime oben gezeigt hat, merke mir die Position bis zu der die letzten Bytes gelesen wurden und versende die Bytes dann. Dann fang ich wieder an ab der Stelle bis zu der bereits eingelesen wurde und lese wieder ein paar Bytes ein, diese versende ich wieder.
Das ganze so oft bis das Ende der Datei erreicht wurde.

Beim Server werden nun die Daten zusammen gesetzt, im OnClientRead Event.

Wenn ich mich recht entsinne war es nur bei UDP so das es Zufall ist ob die Daten in der richtigen Reihenfolge-, und ob die Daten überhaupt, ankommen.

TCP sollte es eigendlich gewähleisten das die Daten in Ein und der Selben Reihenfolge ankommen.
So war es damals bei VisualBasic6.

Dort habe ich das, wie oben beschrieben, verwirklicht.

http://www.tippscout.de/internet-was...tipp_2268.html

Zitat:

TCP leistet Aufgaben wie die Herstellung der Verbindung, die Absicherung gegen Übertragungsfehler, die Aufteilung des anfallenden Datenstroms in Pakete beim Absender und das korrekte Zusammenfügen der Datensegmente beim Empfänger.

Das Ganze hat ja später den Sin das mehrere Dateien zwischen Server und Client transportiert werden können, und das parallel.
Mit der von gandime Beschriebenen Methode vor die Daten eine ID zu hängen, hat ja den Sin das anhand dieser ID beim Server oder Client, das Datenpacket der richtigen Datei (Speicherort) zugeordnet werden kann. Sonst gibt es Datensalat.

[Muetze1]

TCP macht dies, ich habe nichts anderes gesagt. Nur die Teilung wird von vielen Nutzern vorausgesetzt, dass sie beim Empfangen genauso ankommen. Mehr wollte ich nicht sagen, der Hinweis war wohl nicht nötig, von daher ignorier es...

[d1ng0d0gt0r]

Deine Signatur sagt ja schon alles xD.

Nein ich glaube wir haben einfach aneinander vorbei geredet.

Ich dachte das du meintest, das die Daten wenn sie so abgesendet werden:
SendText('1');
SendText('2');
SendText('3');

auch so ankommen können:
SendText('1');
SendText('3');
SendText('2');

Mein Fehler.

[Muetze1]

Nein, viele Leute hier setzen voraus, dass sie das denn auch wieder so empfangen:

Receive('1');
Receive('2');
Receive('3');

aber leider ist es oftmals so:

Receive('12');
Receive('3');

bzw.

Receive('123');

Und dann fallen die Leute aus allen Wolken, weil sie mehr in ihren Code implementieren müssen.

[gandime]

ok dann stell dir das Beispiel mal vor du schickst einen Stream mit diesen Vorzeichen 'File-0000' anschliesend der stream als beispeil 'abcd-0000'

also so wird es versendet:
cs.socket.sendtest('File-0000abcd-0000'); jetzt könnte es ja passieren das die daten so bei dem Server ankommen:
Packet 1:
File-0000abc
Packet 2:
d0000

bei Packet 1 wird dann abc als file erkannt und der Datei hinzugefügt, allerdings bei Packet 2 ist es nicht zugewiesen, womit der Server dann nichts anfangen kann

[d1ng0d0gt0r]

Genau aus dem Grund würde ich die Daten in so kleinen Schnippseln aus der Datei einlesen und versenden, das eben so etwas nicht passiert.