Hallo!

Also wenn ich vom ClientSocket zum ServerSocket einen Stream schicke, und mir dann noch jemand nen String schickt, gibts Probleme, da die Datei dann nicht mehr stimmt. Beim Client will ich jedoch nichts machen wie eine Boolean-Variable dass erst Strings gesendet werden wenn der Server ein "Transfer complete" zurück gibt, denn dann hab ich wieder Probleme mit mehreren Clients etc.

Ich denke ich werde es so machen, dass ich vor dem auswerten der Nachricht den Socket überprüfe um zu sehen wer sendet (Der, der den Stream sendet oder jemand anderes).
Das ist ja nicht das Problem eigendlich

Jetzt brauche ich nur noch eine Lösung um zu erkennen wenn ein normaler String ankommt.
Kann mir jemand nen Ansatz geben?

Danke für alle Antworten!!


greetz

Sowas nennt man Protokoll *g*

Einfach bei Stream-Blöcken und Strings jeweils ne bestimmte Kennung vorausschicken ... Dann sollte das kein Thema sein ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Nun ja, genau das mach ich ja, doch wenn jemand anderes etwas schickt dann geht es ja nicht, denn wenn ich dann in dem Modus bin, in dem ich die Datei empfange wird der String mit rein genommen

Moin!

Born-to-Frag hat folgendes geschrieben:

Nun ja, genau das mach ich ja, doch wenn jemand anderes etwas schickt dann geht es ja nicht, denn wenn ich dann in dem Modus bin, in dem ich die Datei empfange wird der String mit rein genommen

Das Problem bei Streams und Protokollen auf Terminatorzeichenbasis ist, dass man sie nicht (so ohne weiteres) mischen kann...

Du könntest etwa sowas machen:
- Befehl "Stream-Start","x Bytes lang"
- dann auf der Clientseite den Stream in den Socket stecken
- auf der Serverseite die nächsten x Bytes nach dem Kommano (und dem Terminatorzeichen) aus dem Socket in einen Stream fließen lassen
- danach automatisch wieder in den "Befehlsmodus" wechseln

Der "Witz" ist also, die Länge des Streams zu kennen, zu versenden und dann die Bytes mitzuzählen.

cu
Narses

Narses hat folgendes geschrieben:

Moin! Born-to-Frag hat folgendes geschrieben: Nun ja, genau das mach ich ja, doch wenn jemand anderes etwas schickt dann geht es ja nicht, denn wenn ich dann in dem Modus bin, in dem ich die Datei empfange wird der String mit rein genommen Das Problem bei Streams und Protokollen auf Terminatorzeichenbasis ist, dass man sie nicht (so ohne weiteres) mischen kann... Du könntest etwa sowas machen: - Befehl "Stream-Start","x Bytes lang" - dann auf der Clientseite den Stream in den Socket stecken - auf der Serverseite die nächsten x Bytes nach dem Kommano (und dem Terminatorzeichen) aus dem Socket in einen Stream fließen lassen - danach automatisch wieder in den "Befehlsmodus" wechseln Der "Witz" ist also, die Länge des Streams zu kennen, zu versenden und dann die Bytes mitzuzählen. cu Narses

Das mache ich auch schon

Ich kenne immer die Größe der Streams und schalte danach wieder den Modus um. Aber: Wenn ich einen Stream sende, kann dann nie dieser String "zwischen" die Übertragung kommen und irgendwo in den Stream gelangen?

Wenn nicht, dann müsste ich nur noch wissen, wenn der letzte Teil ankommt, wie ich das ende abtrenne wenn das Ende des Stream + Ein Befehl ankommt..

Moin!

Born-to-Frag hat folgendes geschrieben:

Wenn ich einen Stream sende, kann dann nie dieser String "zwischen" die Übertragung kommen und irgendwo in den Stream gelangen?

Naja, da gibt´s bei den Socket-Kompos im asynchronen Modus zugegeben etwas Probleme... Wenn du einen dicken Stream versendest, dann kommt die Methode .SendStream() sofort zurück, die WSA sendet aber im "Hintergrund" fleißig weiter. Wenn du jetzt einen .SendText() dazwischen machst, dann könnte dir das Paket dazwischen kommen, weiß ich aber nicht genau. Lösung: entweder blocking-socket-calls machen oder mit OnWrite() arbeiten, dass Ereignis tritt ein, wenn der Socket fertig ist mit Daten senden (also nach dem Stream).

Fazit: Das ganze wird mit großen Streams "spannend", kleinere (so bis 8kb) sollten keine Probleme machen, die passen nämlich in den WSA-Buffer.

Das ist kein leichtes Problem (leider, ich weiß), das löst man am besten dadurch, dass man den großen Stream in kleine Blöcke zerhackt.

Born-to-Frag hat folgendes geschrieben:

Wenn nicht, dann müsste ich nur noch wissen, wenn der letzte Teil ankommt, wie ich das ende abtrenne wenn das Ende des Stream + Ein Befehl ankommt..

Stream-Ende erkennen: Bytes zählen, ganz simpel! Wenn du sagst, du weißt wie lang der Stream ist, sollte das ja wohl kein Problem sein.

cu
Narses

PS: Wenn ich mir den Titel des Topics so ansehe, habe ich das Gefühl, ich sollte noch zur Sicherheit sagen: Es gibt keinen Unterschied zwischen den Stream-Daten und Strings am Socket, das sind einfach nur Daten. Dein Programm muss wissen, um was für Daten es sich handelt, die da gerade aus dem Socket sprudeln; da liegt eben das Problem -> Protokoll!

Die Streams sind unterschiedlich groß, aber über 8KB, und da sie immer in 8KB blöcken ankommen, weiß ich nicht wie ich das machen soll, denn ich hänge dann immer diesen Block an den Stream dran und beim letzten Block ist dann eben
schwer.
Bisher mach ich immer Socket.ReceiveBuf(Pointer(Int64(rM.Memory) + rM.Position)^, RecLeng)

Mh.. also Soll ich machen [rM is mein Stream]
?

Probier ich Morgen mal aus


//EDIT: Wie kann ich dann das Ende der Blocks in ein String umwandeln?
//EDIT2: Achso.. das ganze funktioniert ja nur wenn nichts "dazwischen" kommt
Was macht genau OnWrite?

Moin!

Ja, so oder ähnlich; wenn du nicht alle Daten aus dem Socket liest, stellt dir die WSA sogar netterweise auch wieder ein FD_READ in die Messagequeue, kommt also wieder´n OnRead() hinterher.

Besser wäre natürlich die Stream-Stücke ins Protokoll zu integrieren und nicht immer einen kompletten Stream am Stück zu senden; ist auch für QoS besser zu handeln.

cu
Narses

PS:

Born-to-Frag hat folgendes geschrieben:

Wie kann ich dann das Ende der Blocks in ein String umwandeln?

Wenn du nicht alles gelesen hast, kriegst du wieder ein OnRead(), dann machste einfach .ReceiveText.

Born-to-Frag hat folgendes geschrieben:

Achso.. das ganze funktioniert ja nur wenn nichts "dazwischen" kommt Was macht genau OnWrite?

S.o. oder DOH, tritt ein, wenn der Socket fertig ist mit Senden.

Hmmm, mir fällt da gerade noch ein anderes "Horror-Szenario" ein: wenn du asynchron einen fetten Stream sendest, dann kommt das .SendStream() ja sofort zurück, es werden aber noch im Hintergrund Daten gesendet (z.B. aus dem Memory-Stream). Was passiert wohl, wenn du jetzt (während dem Senden!) den Mem-Stream freigibst... ... also ganz soo einfach ist das alles nicht!

Ich hab vor etwas längerer Zeit einmal versucht, ein Übertragungs-Protokoll auf IntelHex-Basis zu entwickeln.

Der Witz an dem Protokoll war: Das Teil konnte beliebig viele (in den Grenzen von Speicher und DWORDs) Streams gleichzeitig verarbeiten, ohne das es konflikte gab (selbst mit automatischer Fehlerkorrektur).

Das Teil lief so (Achtung, sehr viel Theorie zum Intel-Hex-Format):

:NNAAAAAAAAPPPPCC????..????SS

Wobei NN die Länge des Datenbereichs, AAAAAAAA der DWORD-Offset im Stream, PPPP die Stream-\Page-ID und CC eine Befehls-ID war. Ferner waren die Fragezeichen die HEX-codierten Daten und SS eine Prüfsumme.

SS ist so zu setzen, dass alle Bytes der Zeile addiert (+SS) ein vielfaches von 256 ergeben.

Damit ließ sich auf jeden Fall erstmal sicherstellen, dass, wenn eine Zeile ankam, diese immer eindeutig dekodierbar war, da ich wusste, dass
- immer 2n+1 Bytes pro Zeile (Zeilenumbrüche ausgenommen) vorhanden waren
- eine Zeile immer mit : anfängt und danach nur HEX-Zeichen kommen dürfen
- eine Prüfsumme vorhanden ist

Wenn also ein Datenblock unterbrochen wurde und ich

:AB00AAABA155645012:1200312012...

erhalten hab, konnt ich diesen Block verwerfen. Ich brauchte am Ende nur mitzuzählen, welche Bytes\Blöcke eines Streams ich schon hatte und ggf. fehlende oder defekte Blöcke erneut anzufordern. Lief auch recht schnell, mal abgesehen davon, dass die Socket-Verbindung nicht die stabilste war.

Ich hab mein Protokoll damals dann auf folgende Befehle aufgebaut:

(Übernommen von IntelHex)
00 Es kommen Daten
01 End Of Stream

Zusätzlich:
02 Page open (bei mir Stream Open)
03 Page close (Stream Ende*)
04 Resend Request*

Wobei bei einem 03 erst dann geschlossen wurde, wenn dies die Gegenstelle auch mit einem 03 bestätigte. Fehlten Daten, wurden diese Blöcke per 04 erneut angefordert.

Meine Geschwindigkeiten lagen damals um die 20 KB\s (128 Bytes pro Block Nutzdaten) ... Haupteinschränkung war aber, dass meine verwendet Kompo bereits Datenverlust hatte, wenn ich die Maus bewegte ...

Hoffe, das ist für dich ein Ansatz, um dein Protokoll zu erweitern.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hallo!

Narses hat folgendes geschrieben:

Besser wäre natürlich die Stream-Stücke ins Protokoll zu integrieren und nicht immer einen kompletten Stream am Stück zu senden; ist auch für QoS besser zu handeln.

Klingt gut! Wie kann ich Streams denn Teilen?

Wie kann ich denn an den von dem Stream gesendetem Block noch mein Protokoll dranhängen?

Das von dir BenBe klingt ziemlich kompliziert ^^ ..
Wie kodiere ich denn einen Stream in Hex?

greetz

@B2F: Einfach Byte für Byte des Streams hernehmen und mit IntToHex ???, 2); kodieren.

Du musst nicht zwangsläufig IntelHex, wie ich es damals getan hab, hernehmen, sondern kannst eigentlich JEDES Protokoll nutzen, was eine Block-Integrität herstellen kann und dabei für deine Zwecke nicht mehr als nötig Overhead erzeugt.

Das Protokoll, was ich damals implementiert hab, war eigentlich von der Implementierung recht simpel (~300 Zeilen für die eigentliche Stream-Verwaltung). Der Rest (~400 Zeilen) kümmerte sich um die Initialisierung und Socket-Verwaltung.

@Streams auseinandernehmen: Einfach nicht mit einem Mal den gesamten Stream senden, sondern immer kleinere Teile (sagen wir 128 Bytes). Protokoll dran hängen heißt auch nur: Vor diesem Teilblock, ähnlich meiner IntelHex-Variante, noch zusätzliche Daten anfügen, die erklären, was eigentlich grad ankommt - was dieser Block zu bedeuten hat.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Also danke schon mal! Hört sich alles realisierbar an
Nur noch mal um sicherzugehen: Ich sende doch dann nur noch String, oder?

Also ich melde mich dann noch mal falls nichts klappt


//EDIT: Wie geh ich denn Byte für Byte durch ?
//EDIT2: So? IntToHex(Str.Seek(i, sofrombeginning), 2); //i: For-Schleife

Nope...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

@Streams auseinandernehmen: Einfach nicht mit einem Mal den gesamten Stream senden, sondern immer kleinere Teile (sagen wir 128 Bytes). Protokoll dran hängen heißt auch nur: Vor diesem Teilblock, ähnlich meiner IntelHex-Variante, noch zusätzliche Daten anfügen, die erklären, was eigentlich grad ankommt - was dieser Block zu bedeuten hat.

Bekomm das doch noch nich so ganz hin

Also mein Problem liegt wohl bei der umwandlung in einen String...
Dann noch eine Frage wegen dem Senden der Teile: Wenn ich das in einer Schleife mache dann kann es ja wieder pasieren das 2Teile auf einmal gesendet werden und irgendwas angeschnitten wird. Oder soll ich nach jedem Empfang ein "ok" oder etwas in dr Art senden?

BenBe hast du vielleicht noch deine Unit oder irgendein Beispiel das du posten willst an dem ich mir das klar machen kann?


greetz

Moin!

Born-to-Frag hat folgendes geschrieben:

Dann noch eine Frage wegen dem Senden der Teile: Wenn ich das in einer Schleife mache dann kann es ja wieder pasieren das 2Teile auf einmal gesendet werden und irgendwas angeschnitten wird.

Wenn du unterhalb der WSA-Buffergröße bleibst (AFAIK 8kb), dann sollte es keine "Überlagerungseffekte" geben, da die einzelnen Socket-Calls nicht unterbrochen werden, bei einem Stream aber nicht der ganze Stream auf einmal gesendet wird, wenn er nicht in den WSA-Buffer passt, sondern in Stücken. Deshalb Vorschlag: nimm 4kb-Segmente.

cu
Narses

Hallo!

Funktioniert soweit, nur bin ich mir nicht sicher, weil ich glaube das es doch passieren kann das 2Teile zusammen ankomen Aber das werd ich dann schon Testen.

Jetzt hab ich aber noch 2 Fragen:
Und zwar hat der Stream ja eine bestimmte Größe, z.B. 170.000. Wenn ich jetzt z.B. den Fortschritt zeigen will, wie geht das? Denn die String-Länge ist ja am Ende der Übertragung nicht 170.000, sondern größer, oder?

Und dann hab ich Probleme bei der Konvertierung der Hex-Strings zum Stream. Klappt nicht so ganz, habe es mit HexToBin versucht und dann MeinStream.Write(), aber das geht nicht


greetz

Moin!

Born-to-Frag hat folgendes geschrieben:

weil ich glaube das es doch passieren kann das 2Teile zusammen ankomen

Wenn du das mit einem "vernünftigen" Protokoll machst, ist das kein Problem, das muss der Protokollparser auflösen können, sonst taugt der nix.

Born-to-Frag hat folgendes geschrieben:

Und zwar hat der Stream ja eine bestimmte Größe, z.B. 170.000. Wenn ich jetzt z.B. den Fortschritt zeigen will, wie geht das? Denn die String-Länge ist ja am Ende der Übertragung nicht 170.000, sondern größer, oder?

Wenn du die binärdaten in HexStrings umwandelst, dann ist der Faktor 2! Das ist mal nicht ganz unheftig, also für 1 MB Nutzdaten überträgst du 2 MB + Protokolloverhead... da wäre ein Binärprotokoll vermutlich besser (ich plaudere mal aus dem Nähkästchen: ich Arbeite gerade an einem Bin-Proto-Tut... )

Born-to-Frag hat folgendes geschrieben:

Und dann hab ich Probleme bei der Konvertierung der Hex-Strings zum Stream. Klappt nicht so ganz, habe es mit HexToBin versucht und dann MeinStream.Write(), aber das geht nicht

Hatte am Anfang auch Probleme mit HexToBin, hat irgendwie komisch rumgezickt, die Prozedur. Kann mich aber nicht mehr genau erinnern... naja, hilft jetzt wohl nicht gerade viel, diese Aussage.

cu
Narses

Ich habe immer noch große Probleme beim codieren/decodieren meines Streams.
Ich habe jetzt alles überprüft und irgendwo liegt dort der fehler. Die Codieren Zeichen die der Client sendet, und die, die der Server empfängt, enthalten keine fehler.

Also hier mal die codierung in HEX:



decodieren:



Vielleicht findet ja jemand den Fehler für mich


greetz


EDIT: Mal ein Beispiel, was ich auf meiner boot.ini für einen Text bekommen habe:


EDIT2: Ok geschafft, BenBe hat mir geholfen =)