createReadStream fuktionert nicht wie erwartet.

[xorg1990]

Hi, ich möchte über eine Websocket Verbindung eine große wav Datei streamen.

dafür wollte ich createReadStream nutzen um chunks zu erzeugen.


Es kommt zwar ein arraybuffer der mit der Länge des chunks übereinstimmt beim Client an, aber die Daten, die beim client ankommen sind leer.

Also im Arraybuffer sind nur Nullen.

fs.stat(file, function(err,stats){
			var opts = {
					flags: "r",
					encoding : null,
					mode: 0666,
					fd: null,
					autoClose : true,
					highWaterMark: 128*1024,
					start: 46
			}
			rStream = fs.createReadStream(file,opts);
			var i= 0;
			rStream.on("data", function(chunk){
				if(i++<20){
					console.log(typeof chunk ,chunk.length)
					ws.send(chunk.buffer);
				}
			})
		});

bei encoding : null ist typeof chunk = Objeckt und bei encoding : "binary", ist typeof string.

Wo ist der Haken? Funktioniert createReadStream nur mit Text Dateien?

- - - Aktualisiert - - -

Gefindet, lag am if anscheint sind die ersten 20 chunks leer, aber das ist unsinnig, da die wav Datei nicht leer ist.
Nehme ich das if weg haut er mir die ganze Datei in den äther, was zu folge hat das der Client einfriert und Nodejs auch.

gibt da ein paar nette module : https://www.npmjs.com/package/advanced-throttle
aber rwie komme ich von den throttle zu der ws connection?

Man könnte auch in jeden readStream Callback ein setTimout machen aber ist das die Lösung??

[kkapsner]

Warum willst du die Datei überhaupt über das WS senden? Dafür ist doch normales HTTP viel besser geeignet.

[xorg1990]

Da hast du recht HTTP ist da einfacher, aber mir geht um den Datenschutz, z.B reicht es weget http//adresse/zur/datei einzu geben und die Datei wird gedownloadeed.

Bin aber jetzt dahinter gekommen das die Media Source Extenson kein wav unterstützen. Bleibt mir nur noch HTTP aus Datenschutz gründen arbeite ich mit cookies um zu erkenne das der Request von der Seite kommt.

Aber sicher ist kein Stream, außer der von yt, da kommt man nicht ran.

[tsseh]

Aber sicher ist kein Stream, außer der von yt, da kommt man nicht ran.

natürlich kommt man da ran! an alles was du dir ansehen kannst, kommst du auch ran

[xorg1990]

natürlich kommt man da ran! an alles was du dir ansehen kannst, kommst du auch ran

Sicherlich mit mit einer in C geschrieben Anwendung und viel Hexerei aber mal so so eben den http Stream capturen kein chance.
Zumal der stream alles einzelne Ajax Requests sind.

[kkapsner]

Du kannst ja auch dynamische, einmal URLs verwenden und die URL per WS schicken.

PS: VLC kann Youtube Videos "abspielen".

[mikdoe]

aber mal so so eben den http Stream capturen kein chance.

Mal mit https://www.wireshark.org/ versucht?

Zumal der stream alles einzelne Ajax Requests sind.

Die Herkunft ist Wireshark egal.

[xorg1990]

Jo, Wireshark genial, damit habe ich früher mal Handys gehackt^^. Bei YouTube musst man halt aufpassen das du die Daten richtig zusammen setzt, die Datei wird nicht nach einander abgefasst. Logisch Google möchte sich Datenschutz technisch so gut wie möglich absichern. Und du mussst mit wireshark https request senden können, jeder chunk hat eine andere id.

[mikdoe]

Und du mussst mit wireshark https request senden können, jeder chunk hat eine andere id.

Das geht mit WS. Müsste ich mal suchen, wenn das helfen würde.

[xorg1990]

Nee lass mal, es ist nicht mein Zeil Youtube zu hacken. War schon 5 mal im Leben beim Anwalt^^ Das kostet nur Geld.

Bei YT ist es so das die Daten geclustert werden. Mit jeder ajax responce erhalst du die ID wo, auf welcher festplatte das nächste chunk sich befindet.

https://r1---sn-h0jeener.googlevideo.com/videoplayback?id=o-AHUgUSZUDbc7EboHoZXR8j6Zn7U7OpOTfZym8Y3mHjcT&ms=au&mt=1516830620&mv=m&expire=1516852309&requiressl=y es&mime=video%2Fwebm&ip=2003%3A6%3A2398%3A7735%3Ac8c0%3A18e%3Aaa95%3A1398&mm=31&source=youtube&pl=52 &mn=sn-h0jeener&ei=8_9oWurDOM-kW-jMr5gP&gir=yes&sparams=aitags%2Cclen%2Cdur%2Cei%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeep alive%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cexpire&lmt=1515632314027436&beid s=%5B9466591%5D&initcwndbps=833750&ipbits=0&dur=867.999&signature=29F4D052C8502B4C49292A2768DFC566D8 C6C4DA.97AFA8891C89A751B7D0A5346701D56E12A255DE&clen=287031128&aitags=133%2C134%2C135%2C136%2C137%2C 160%2C242%2C243%2C244%2C247%2C248%2C278%2C298%2C299%2C302%2C303&itag=302&key=yt6&keepalive=yes&rateb ypass=yes&alr=yes&cpn=_tTmoTvDXTRFoxet&c=WEB&cver=2.20180122&range=5967771-8064922&rn=11&rbuf=11792

https://r1---sn-h0jeener.googlevideo.com/videoplayback?id=o-AHUgUSZUDbc7EboHoZXR8j6Zn7U7OpOTfZym8Y3mHjcT&ms=au&mt=1516830620&mv=m&expire=1516852309&requiressl=y es&mime=audio%2Fwebm&ip=2003%3A6%3A2398%3A7735%3Ac8c0%3A18e%3Aaa95%3A1398&mm=31&source=youtube&pl=52 &mn=sn-h0jeener&ei=8_9oWurDOM-kW-jMr5gP&gir=yes&sparams=clen%2Cdur%2Cei%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeepalive%2Cl mt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cexpire&lmt=1515631553273674&beids=%5B9466 591%5D&initcwndbps=833750&ipbits=0&dur=868.021&signature=C8AE5157FCC5B06F18B9D96D5123F557A71B2499.58 44BEF4AA2FB572ED0A187905EE2B97B4A224B5&clen=14667529&itag=251&key=yt6&keepalive=yes&ratebypass=yes&a lr=yes&cpn=_tTmoTvDXTRFoxet&c=WEB&cver=2.20180122&range=494031-559566&rn=30&rbuf=0

Wenn du das in die Adresszeile einfügst passiert nix, naja es passiert schon was aber...

- - - Aktualisiert - - -

Noch was Produzieren die ganze request/respnces nicht total Overhead? Wäre nicht ein Socket Verbindung effizienter, war ja damals beim Flashplayer auch so.

[kkapsner]

Die ganzen Requests/Responses sind wahrscheinlich stabiler. V.a. wenn man mobile Datenverbindungen in Betracht zieht.