Netzwerk - Dateiübertragung unvollständig

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	Sereiya Betreff: Netzwerk - Dateiübertragung unvollständig	Fr, Mai 07, 2010 17:39 Antworten mit Zitat
Hallo, Ich bin momentan am Programmieren eines Server-Client Programmes für verschiedene Aufgaben. Bin momentan am versuchen, eine Datei zu übertragen (BNetEx), z.B. ein Bild. Das kommt aber i.d.R. unvollständig an.. Die Datei die ankommt ist immer auf einen Wert gerundet, bei einer vorher 37,2kb großen Datei kommt nachher eine 36kb große heraus, weiß aber nicht warum. Ich lasse die Datei Clientseitig mit ReadFile einlesen, und sage ihm mit CopyStream das er den Streaminhalt auf den Serverstream schieben soll. dann schicke ichs ab. der Server ruft das daraufhin ab, und schreibt das Byteweise direkt in die Zieldatei, bis Eof = True ist. Gibt es irgendwas, was ich bei sowas beachten muss? Wäre superdankbar wenn mir jemand da weiterhelfen könnte. lg Serry

Sereiya

Betreff: Netzwerk - Dateiübertragung unvollständig

Fr, Mai 07, 2010 17:39
Antworten mit Zitat

Hallo,

Ich bin momentan am Programmieren eines Server-Client Programmes für verschiedene Aufgaben. Bin momentan am versuchen, eine Datei zu übertragen (BNetEx), z.B. ein Bild. Das kommt aber i.d.R. unvollständig an..
user posted image

Die Datei die ankommt ist immer auf einen Wert gerundet, bei einer vorher 37,2kb großen Datei kommt nachher eine 36kb große heraus, weiß aber nicht warum. Ich lasse die Datei Clientseitig mit ReadFile einlesen, und sage ihm mit CopyStream das er den Streaminhalt auf den Serverstream schieben soll. dann schicke ichs ab. der Server ruft das daraufhin ab, und schreibt das Byteweise direkt in die Zieldatei, bis Eof = True ist.

Gibt es irgendwas, was ich bei sowas beachten muss? Wäre superdankbar wenn mir jemand da weiterhelfen könnte.

lg
Serry

	skey-z	Fr, Mai 07, 2010 19:57 Antworten mit Zitat
Schickst du das Bild in einem oder Teilweise, weil die 36KB die Übertragen werden scheinen eine Begrenzung zu sein, versuch es doch mal in Blöcken zu senden, erst schickst du die Anzahl der Blöcke, damit der Client weis, wieviele Teilbilder er erwarten kann und danach setzt er sie wieder zu einem Bild zusammen.
Awards: Coffee's Monatswettbewerb Feb. 08: 1. Platz BAC#57: 2. Platz Twitter

skey-z

Fr, Mai 07, 2010 19:57
Antworten mit Zitat

Schickst du das Bild in einem oder Teilweise, weil die 36KB die Übertragen werden scheinen eine Begrenzung zu sein, versuch es doch mal in Blöcken zu senden, erst schickst du die Anzahl der Blöcke, damit der Client weis, wieviele Teilbilder er erwarten kann und danach setzt er sie wieder zu einem Bild zusammen.

Awards:
Coffee's Monatswettbewerb Feb. 08: 1. Platz
BAC#57: 2. Platz
Twitter

	Lion	Fr, Mai 07, 2010 22:54 Antworten mit Zitat
Hatte das problem auch mal Lösung: Schicke erst einen Integer, der FileSize(Datei) angibt, dann machst du solange Repeat Forever bis das pensum erreicht ist, dann einfach Exit und Closefile. Funzt wie geschmiert, liegt daran, dass er ab ner bestimmten größe iwie nicht immer alles auf einmal schickt...
Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

Lion

Fr, Mai 07, 2010 22:54
Antworten mit Zitat

Hatte das problem auch mal

Lösung: Schicke erst einen Integer, der FileSize(Datei) angibt, dann machst du solange Repeat Forever bis das pensum erreicht ist, dann einfach Exit und Closefile. Funzt wie geschmiert, liegt daran, dass er ab ner bestimmten größe iwie nicht immer alles auf einmal schickt...

Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb
Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb
AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

	juse4pro	Mo, Jan 16, 2012 2:04 Antworten mit Zitat
Ich grab mal diesen Klumpen hier aus, denn ich habe das selbe Problem und kann mit dieser Beschreibung der Lösung wenig anfangen. (Nichts für ungut) Ich zerschneide meine Datei auch in Teile und sende diese einzeln. Jedoch krepert er nicht immer. Obwohl ich per WriteString (was ja eine anzahl an Bytes schreibt) schicke, und auf der anderen Seite mit ReadString lese, sind manchmal einfach zu wenig Bytes drin. (z.b. von 2048 Bytes sind nur 1045 im Paket enthalten, was zu einem Lesefehler führt) Nur komisch, dass der Fehler sporadisch auftritt, z.b. manchmal beim 5. oder 6. Part der Datei (von 9). Umso größer die Teilpaket-Größen, desto häufiger kommt der Fehler. Bei 1024 Bytes z.b. nie. Bei 10240 Bytes, immer sofort beim ersten Part. Vielleicht kann ja jemand helfen, weil ich dachte, dass TCP sich eigentlich darum kümmert, dass alles ankommt. -> Ich verwende auch BNetEx

juse4pro

Mo, Jan 16, 2012 2:04
Antworten mit Zitat

Ich grab mal diesen Klumpen hier aus, denn ich habe das selbe Problem und kann mit dieser Beschreibung der Lösung wenig anfangen. (Nichts für ungut)

Ich zerschneide meine Datei auch in Teile und sende diese einzeln. Jedoch krepert er nicht immer. Obwohl ich per WriteString (was ja eine anzahl an Bytes schreibt) schicke, und auf der anderen Seite mit ReadString lese, sind manchmal einfach zu wenig Bytes drin. (z.b. von 2048 Bytes sind nur 1045 im Paket enthalten, was zu einem Lesefehler führt)
Nur komisch, dass der Fehler sporadisch auftritt, z.b. manchmal beim 5. oder 6. Part der Datei (von 9). Umso größer die Teilpaket-Größen, desto häufiger kommt der Fehler. Bei 1024 Bytes z.b. nie. Bei 10240 Bytes, immer sofort beim ersten Part.

Vielleicht kann ja jemand helfen, weil ich dachte, dass TCP sich eigentlich darum kümmert, dass alles ankommt.

-> Ich verwende auch BNetEx

	Jan_ Ehemaliger Admin	Mo, Jan 16, 2012 11:00 Antworten mit Zitat
Dann nutze nciht writestring sonder: Writebank
between angels and insects

Jan_

Ehemaliger Admin

Mo, Jan 16, 2012 11:00
Antworten mit Zitat

Dann nutze nciht writestring sonder: Writebank

between angels and insects

	Midimaster	Mo, Jan 16, 2012 11:40 Antworten mit Zitat
Diesen Fehler hatte ich auch schon mal und habe dann einfach die Paketgröße auf 256 reduziert. Dort gab es nie Fehler. Der Zeitverbrauch steigt etwas an.
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

Midimaster

Mo, Jan 16, 2012 11:40
Antworten mit Zitat

Diesen Fehler hatte ich auch schon mal und habe dann einfach die Paketgröße auf 256 reduziert. Dort gab es nie Fehler. Der Zeitverbrauch steigt etwas an.

Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

	juse4pro	Mo, Jan 16, 2012 11:54 Antworten mit Zitat
Die Paketgröße auf 256 zu reduzieren würde die Zeit einfach VIEL zu weit hochtreiben... ich würde gern bei 10 KiloByte bleiben @Jan: WriteBank schreibt doch eine Bank in einen Stream, ich hab' noch nie mit Banks gearbeitet, wie packe ich die Daten erst in die Bank, um diese dann in den Stream zu kloppen?

juse4pro

Mo, Jan 16, 2012 11:54
Antworten mit Zitat

Die Paketgröße auf 256 zu reduzieren würde die Zeit einfach VIEL zu weit hochtreiben... ich würde gern bei 10 KiloByte bleiben Wink

@Jan: WriteBank schreibt doch eine Bank in einen Stream, ich hab' noch nie mit Banks gearbeitet, wie packe ich die Daten erst in die Bank, um diese dann in den Stream zu kloppen?

	Jan_ Ehemaliger Admin	Mo, Jan 16, 2012 12:34 Antworten mit Zitat
natrülich haust du sie erst in die Bank. 10 Kilobyte? ich würde mich so um die 1-2 Kilobyte anreihen. in den Streams gibt es bestimmt auch was zum data schreiben, aber da musste mal selber den Source durchschauen, von TStream.
between angels and insects

Jan_

Ehemaliger Admin

Mo, Jan 16, 2012 12:34
Antworten mit Zitat

natrülich haust du sie erst in die Bank.
10 Kilobyte? ich würde mich so um die 1-2 Kilobyte anreihen.
in den Streams gibt es bestimmt auch was zum data schreiben, aber da musste mal selber den Source durchschauen, von TStream.

between angels and insects

	Midimaster	Mo, Jan 16, 2012 12:46 Antworten mit Zitat
hast du denn mal mit den 256 ausprobiert? Wäre ja vielleicht ein guter Test, um zu prüfen, ob das Problem vielleicht von einer anderen Stelle des Algo herrührt... ich sende immer 30 Blocks a 256 Bytes, was 7.7kByte pro Step ausmacht. Die Unterbrechung hat sich als sinnvoll herausgestellt, weil man dann auch noch eine Progressbar optisch mitlaufen lassen kann. Übrigens schreibe ich am Ende die Daten sogar mit einem weiteren CopyStream() aus dem InternetStream in die Zieldatei. Möglicherweise ist dies schneller als die EinzelBytes?
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

Midimaster

Mo, Jan 16, 2012 12:46
Antworten mit Zitat

hast du denn mal mit den 256 ausprobiert? Wäre ja vielleicht ein guter Test, um zu prüfen, ob das Problem vielleicht von einer anderen Stelle des Algo herrührt...

ich sende immer 30 Blocks a 256 Bytes, was 7.7kByte pro Step ausmacht. Die Unterbrechung hat sich als sinnvoll herausgestellt, weil man dann auch noch eine Progressbar optisch mitlaufen lassen kann.

Übrigens schreibe ich am Ende die Daten sogar mit einem weiteren CopyStream() aus dem InternetStream in die Zieldatei. Möglicherweise ist dies schneller als die EinzelBytes?

Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

	Tankbuster	Mo, Jan 16, 2012 13:14 Antworten mit Zitat
Zitat: Ein TCP-Segment hat typischerweise eine Größe von maximal 1500 Bytes. Ein TCP-Segment muss jedoch in die darunter liegende Übertragungsschicht passen, das Internetprotokoll (IP); siehe hierzu auch Maximum Transmission Unit. IP-Pakete wiederum sind zwar theoretisch bis 65.535 Bytes (64 KiB) spezifiziert, werden aber selbst meist über Ethernet übertragen, und bei Ethernet ist die Rahmengröße (wenn man von Jumbo Frames absieht) auf 1500 Bytes festgelegt. TCP- und IP-Protokoll definieren jeweils einen Header von 20 Bytes Größe. Für die Nutzdaten bleiben in einem TCP/IP-Paket also 1460 Bytes (= 1500 Bytes [Nutzdaten] − 20 Bytes Headerdaten TCP − 20 Bytes Headerdaten IP) übrig. Da die meisten Internet-Anschlüsse DSL verwenden, kommt dort zusätzlich noch das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung, was weitere acht Bytes für den PPP-Rahmen verbraucht. Die Nutzdaten reduzieren sich also auf insgesamt 1500 − 20 − 20 − 8 = 1452 Bytes MSS (Maximum Segment Size). Dies entspricht einer Nutzdatenrate von 96,8 %. wiki.
Twitter Download Jewel Snake! Windows\|Android

Tankbuster

Mo, Jan 16, 2012 13:14
Antworten mit Zitat

Zitat:

Ein TCP-Segment hat typischerweise eine Größe von maximal 1500 Bytes. Ein TCP-Segment muss jedoch in die darunter liegende Übertragungsschicht passen, das Internetprotokoll (IP); siehe hierzu auch Maximum Transmission Unit.

IP-Pakete wiederum sind zwar theoretisch bis 65.535 Bytes (64 KiB) spezifiziert, werden aber selbst meist über Ethernet übertragen, und bei Ethernet ist die Rahmengröße (wenn man von Jumbo Frames absieht) auf 1500 Bytes festgelegt. TCP- und IP-Protokoll definieren jeweils einen Header von 20 Bytes Größe. Für die Nutzdaten bleiben in einem TCP/IP-Paket also 1460 Bytes (= 1500 Bytes [Nutzdaten] − 20 Bytes Headerdaten TCP − 20 Bytes Headerdaten IP) übrig. Da die meisten Internet-Anschlüsse DSL verwenden, kommt dort zusätzlich noch das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung, was weitere acht Bytes für den PPP-Rahmen verbraucht. Die Nutzdaten reduzieren sich also auf insgesamt 1500 − 20 − 20 − 8 = 1452 Bytes MSS (Maximum Segment Size). Dies entspricht einer Nutzdatenrate von 96,8 %.

wiki.

Twitter
Download Jewel Snake!
Windows|Android

	juse4pro	Mo, Jan 16, 2012 16:23 Antworten mit Zitat
Midimaster, wie meinst du das? 256 Bytes.. Kein problem... Aber dafür müsste ich mehrere Tausend Pakete senden, damit eine Megabyte-Datei übertragen wird. Du redest von 30 "Blöcken", was meinst du genau? Und was ist bei dir eine Step? Tankbuster, danke... ich habe auch nach Maximal-Größen geschaut, aber nix gefunden... jetzt erklärt sich auch diese merkwürdige 1450 Bytes-Kette am Ende, obwohl mehr drin sein sollten. Kurioserweise sind aber manchmal(!) alle Bytes drin, was den 1500 Byte-Rahmen sprengen würde.

juse4pro

Mo, Jan 16, 2012 16:23
Antworten mit Zitat

Midimaster, wie meinst du das? 256 Bytes.. Kein problem... Aber dafür müsste ich mehrere Tausend Pakete senden, damit eine Megabyte-Datei übertragen wird. Du redest von 30 "Blöcken", was meinst du genau? Und was ist bei dir eine Step? Very Happy

Tankbuster, danke... ich habe auch nach Maximal-Größen geschaut, aber nix gefunden... jetzt erklärt sich auch diese merkwürdige 1450 Bytes-Kette am Ende, obwohl mehr drin sein sollten. Kurioserweise sind aber manchmal(!) alle Bytes drin, was den 1500 Byte-Rahmen sprengen würde.

	Midimaster	Mo, Jan 16, 2012 19:20 Antworten mit Zitat
ja, dem Computer ist da ja aber egal, wieviele Pakete Du sendest.... Bei den großen Dateien dauert es immer etwas Zeit. In dieser Zeit "pausiert" das Programm für den User. Deshalb machte ich die Not zur Tugend und holen nun pro Aufruf der Transferfunktion immer 30x 256 Bytes ab. Dann springt die Funktion in das Hauptprogramm zurück. Dort könnte man dann z.b. einen Fortschrittsbalken anzeigen, oder das Ganze völlig im "Hintergrund" laufen lassen. Bei Browsern ist dies ja auch so ("Download-Fenster") So stört der Zeitbedarf den User nicht mehr so sehr. Die 30 war völlig willkürlich gewählt. so hole ich bei jedem Aufruf 7.7 kByte und bei 10 Aufrufen pro Sekunde immer 77kB/sec, was so ziemlich einer DSL1000 Verbindung entspricht. Ich hatte Dir die 256 zu diesem Zweck: Du sollst damit testen, ob wenigsten diese Rate fehlerfrei durchgeht. Wenn ja, testest Du mal die 512. [Nachtrag] Mit der 256 ergab sich übrigens die beste Performance. Bei 512 stockt es bei meinen Versuchen derart, dass die Übertragung insgesamt längert dauerte.
Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

Midimaster

Mo, Jan 16, 2012 19:20
Antworten mit Zitat

ja, dem Computer ist da ja aber egal, wieviele Pakete Du sendest....

Bei den großen Dateien dauert es immer etwas Zeit. In dieser Zeit "pausiert" das Programm für den User. Deshalb machte ich die Not zur Tugend und holen nun pro Aufruf der Transferfunktion immer 30x 256 Bytes ab. Dann springt die Funktion in das Hauptprogramm zurück. Dort könnte man dann z.b. einen Fortschrittsbalken anzeigen, oder das Ganze völlig im "Hintergrund" laufen lassen. Bei Browsern ist dies ja auch so ("Download-Fenster")

So stört der Zeitbedarf den User nicht mehr so sehr. Die 30 war völlig willkürlich gewählt. so hole ich bei jedem Aufruf 7.7 kByte und bei 10 Aufrufen pro Sekunde immer 77kB/sec, was so ziemlich einer DSL1000 Verbindung entspricht.

Ich hatte Dir die 256 zu diesem Zweck: Du sollst damit testen, ob wenigsten diese Rate fehlerfrei durchgeht. Wenn ja, testest Du mal die 512.

[Nachtrag]
Mit der 256 ergab sich übrigens die beste Performance. Bei 512 stockt es bei meinen Versuchen derart, dass die Übertragung insgesamt längert dauerte.

Gewinner des BCC #53 mit "Gitarrist vs Fussballer" http://www.midimaster.de/downl...ssball.exe

	juse4pro	Mo, Jan 16, 2012 19:39 Antworten mit Zitat
Habe jetzt mal die Bytezahl 1024 pro Part eingestellt... Jedoch bleibe ich bei einem Datendurchsatz von 6500 Bytes/Sekunde... Ich versteh nicht, wo ich noch Performance sparen soll. EDIT: 1024 geht schneller als 256 Bytes (bei mir) mit 1024 bin ich bei 27000 Bytes / s (bei 256 Bytes waren es 6500)

juse4pro

Mo, Jan 16, 2012 19:39
Antworten mit Zitat

Habe jetzt mal die Bytezahl 1024 pro Part eingestellt... Jedoch bleibe ich bei einem Datendurchsatz von 6500 Bytes/Sekunde... Sad

Ich versteh nicht, wo ich noch Performance sparen soll.

EDIT:
1024 geht schneller als 256 Bytes (bei mir)
mit 1024 bin ich bei 27000 Bytes / s (bei 256 Bytes waren es 6500)

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Netzwerk - Dateiübertragung unvollständig

Betreff: Netzwerk - Dateiübertragung unvollständig