Technische Frage zu bspw. Citrix

[Mickey Cohen]

Hallo,

hätte da mal aus interesse eine technische frage: wie funktioniert eigentlich bspw. citrix, wenn man darüber am ipad auf einer windows-vm arbeitet?

ist der bildschirminhalt der windows-vm, den man da zu gesicht bekommt, ein videostream vom server, auf dem die vm läuft?

falls ja:
1. das kostet doch ziemlich viel bandbreite?
2. das encodieren kostet doch sicher auch ein bisschen rechenleistung? wer übernimmt das? die cpu vom server? da müsste man ja schonmal ein, zwei kerne nur fürs encodieren abstellen.

danke

 

[mitch-dk]

Hier ein wenig Bettlektüre. Beantwortet nicht alles, aber man kann sich da weiterhangeln.
Citrix ist einfach nur eine weiterverwurstung von bestehenden Methoden - mehr oder weniger schlecht.

https://www.computerweekly.com/de/definition/Citrix-XenApp
https://searchvirtualdesktop.techtarget.com/definition/Remote-Desktop-Session-Host-RDSH
https://www.citrix.com/de-de/digital-workspace/hdx/

Beim letzten Link ist auch ein Video mit bei, was das so ungefähr zeigt..
Hoffe hilft Dir etwas weiter.

 

[supastar]

Du arbeitest einfach direkt auf dem Server, wie ein Servers in der Cloud (Internet), nur eben in einer Private Cloud.
Die Rechenlast übernimmt der Server.

 

[Mickey Cohen]

ok, ich will einfach allgemein wissen, wie das technisch funktioniert, auf einem remote-server zu arbeiten.

bspw. windows 10 server: wie schickt der das bild an den client? mal angenommen, ich öffne in einer remote desktop session ms paint.

1. möglichkeit:
der server sagt dann bspw. dem client: "zeichne normales fenster, größe x*y, position x;y, zeichne menüleiste,
zeichne menüleistenbutton mit beschriftung [Datei],
..."
der server beschreibt dem client also, wo er welche GUI-elemente zu zeichnen hat.
der vorteil ist hier eine deutlich geringere bandbreite und kein qualitätsverlust durch etwaige kompression. der nachteil ist, dass sich das bild selbst nicht mit dieser GUI-beschreibenden sprache beschreiben lässt.

2. möglichkeit:
der server rendert den bildschirminhalt und encodiert ihn als videostream und sagt dem client: "decodiere bzw. spiel den videostream, den ich dir schicke".
der nachteil hierbei ist das erfordernis von mehr rechenleistung, da eine encodierung des videostreams stattfinden muss, sowie die höhere bandbreite, die die übertragung des videostreams vom server zum client benötigt. ausserdem ist das bild ggf. je nach kompressionsrate umschöner.
der vorteil ist, dass eben auch elemente übertragen werden können, die nicht durch die GUI-beschreibung beschrieben werden können. im beispiel mit paint wäre das eben das bild selbst.

am besten wäre also eine kombination aus beiden methoden: bzgl. der GUI-elemente könnte man methode 1 verwenden, bzgl. des bildes selbt methode 2. das würde dann so aussehen:
der server sagt dem client "zeichne normales fenster, zeichne menüleiste, ... spiele in bestimmten bereich videostream ab"

läuft das in etwa so?

 

[BFF]

Sehr einfach gesagt ist es so.

Der Server (Windows 10 ist kein Server) macht die Arbeit und sendet dem Client nur die Aenderungen am Bildschirm.

Und nein, es ist kein Videostream.
Wenn z.B. absolut nix auf dem Desktop sich aendert, gehen kaum Daten ueber die Leitung. Bei einem Stream ist das etwas anders.

Such einfach mal nach Terminalserver und wie der funktioniert.

BFF

 

[Mickey Cohen]

naja je nach kompressionsverfahren gehen doch auch bei einem videostream bei einem "standbild" kaum daten von der quelle zum ziel, oder?
mit standbild meine ich hier absolute pixelidentität von aufeinanderfolgenden frames zumindest über einen großen bereich des bildes hinweg.
also quasi ein informationstheoretisches standbild und kein bloss faktisches standbild, das man erhält, wenn man bspw. ein wandgemälde filmt. denn im bloß faktischen standbild ändern sich die bildinformationen wegen technischer toleranzen der bildsensoren, flackernden lichtquellen etc. ja stets ein bisschen, wenn auch kaum wahrnehmbar.
diese minimalen veränderungen, die auf der analogen welt beruhen hat man bei einer gerenderten quelle, die sich nicht bewegt ja nicht. wenn man also eine unbewegte gerenderte quelle encodiert erhält man ein "informationstheoretisches standbild". und da lohnt es sich allemal im kompressionsverfahren festzulegen, "was sich nicht ändert wird nicht erneut übertragen". ich bin mir sicher, dass das auch so in den gängigen kompressionsverfahren implementiert ist.

also noch vereinfachter gefragt:

wenn ich einen "ok"-button im client sehe, wie kommt der zum client?

sagt der server: "client, zeichne einen ok-button, du weisst, wie der aussieht, die entsprechenden resources hast du in deinen client-bibliotheken"

oder zeichnet der server den ok-button selbst und sendet seine eigene zeichnung per stream an den client?

 

[Raijin]

Natürlich versucht eine Remote Desktop Anwendung - sei es VNC, RDP, Citrix oder was auch immer - Bandbreite zu sparen. Das schließt je nach Einstellung auch mit ein, dass nur Teile des Bildschirms übertragen werden. Deswegen sind solche Anwendungen nicht wirklich gut dafür geeignet, Videos auf dem Server darzustellen.

Auch wird das Bild nicht zwingend als JPEG oder gar Bitmap übertragen, sondern zT eben auch digitalisiert. Dabei kommt auch Mustererkennung zum Einsatz wie es beispielsweise bei Scannern auch der Fall ist. Statt also "99999" als Ganzes zu übertragen, wird eine 9 als Muster erkannt und dann dupliziert. Bei VNC ist mir das mal aufgefallen. Vermutlich durch eine ungünstige Kombination aus Schriftart, Auflösung und Veränderung der Zahl am Ziel sowie den Qualitätseinstellungen von VNC konnte ich beobachten, dass aus einer 6 eine 8 wurde - ganz ähnlich wie es vor ein paar Jahren bei Xerox-Scannern durch die Presse ging.

 

[supastar]

also noch vereinfachter gefragt:

wenn ich einen "ok"-button im client sehe, wie kommt der zum client?

sagt der server: "client, zeichne einen ok-button, du weisst, wie der aussieht, die entsprechenden resources hast du in deinen client-bibliotheken"

oder zeichnet der server den ok-button selbst und sendet seine eigene zeichnung per stream an den client?

Der Client macht dabei eigentlich gar nichts, außer die Daten des geänderten Bildschirminhaltes zu empfangen.

Also eher Option 2. Ob man das als Stream bezeichnen kann, lass ich mal außen vor.

EDIT(h) sagt:
https://de.wikipedia.org/wiki/Terminalserver
https://de.wikipedia.org/wiki/Virtual_Network_Computing
https://de.wikipedia.org/wiki/Remote_Framebuffer_Protocol