Socket Remote Administration Tool / Fernwartungsprogramm

[Speedy_92]

Hallo Leute,
ich habe mich die letzten paar Wochen mit Netzwerkprogrammierung beschäftigt und ein wenig mit Server-Client Anwendungen herumgespielt. Ich habe ein laienhaftes Fernwartungsprogramm geschrieben, dass Nachrichten versenden konnte, das Dateisystem darstellen und Screenshots erstellen konnte. Nun werde ich das ganz von Grund auf neu beginnen und es ein wenig professioneller gestalten. Dazu habe ich ein paar Fragen.

Einige der von mir angestrebten Funktionen werden sein:
-Dateisystem
-Remote Desktop + Screenshots
-System-Infos
(-Chat)
(-Keylogger)
-Dateien hoch- und herunterladen
-Prozessmanager
-Remote-Konsole
-Registry-Editor

Ich bin recht zuversichtlich, dass dies alles zu realisieren ist.
Es wird so ausfallen, dass jeweils ein Server nur von einem Clienten gesteuert werden kann und er dann "locked" wird, damit kein anderer darauf zugreifen kann. Ein Client kann aber mehrere Server steuern. Dort fängt aber schon das erste Problem an. Wäre es schlauer, das steuerne Element als Server oder Clienten auszurichten? Denn auf der Seite des Servers wird es sicher Probleme mit der Portfreigabe im Router geben, wenn dort eine Firewall vorsitzt. Das ist eigentlich kein Problem und muss ja schließlich nur eingerichtet werden, aber wie herum würdet ihr das realisieren?

Der Datentransfer soll natürlich verschlüsselt werden. Reicht dazu eine RSA-Verschlüsselung aus? Oder gibt es eine effektivere und elegantere Methode die Daten zu verschlüsseln? Sollte der Benutzer selber für den Schlüssel verantwortlich sein oder wäre es vielleicht die bessere Wahl, wenn die Mac-Adresse oder ähnliches als Schlüssel benutzt wird?
Ist es wirklich notwendig alles zu verschlüsseln oder nur interessant, wenn Passwörter oder ähnliche wichtige Informationen übertragen werden?

Als Protokoll werde ich für Dateientransfer und ähnliches TCP benutzen. Ist es empfehlenswert für den Remotedesktop zum Beispiel UDP zu benutzen, da man hier ja nur den Bildschirm sieht und es nicht so entscheidend ist, wenn ein paar Informationen auf dem Weg verloren gehen.

Ist es sehr ressourcenfressend, wenn ich für jede neue Verbindung einen neuen Thread starte? Ich kann es sicherlich so realisieren, dass ich nur wenige Threads für alles benötige, allerdings würde es das ganze wahrscheinlich unübersichtlicher in der Programmierung machen.

Ich denke das war es erst einmal.

Gruß,
Speedy_92

 

[irgendjemand]

ich habs mir jetzt nicht komplett durchgelesen ... aber als "laie" ist das denke ich mal eine hutnummer zu groß ...

alleine ein "live" desktop ist mit java so schon schwer da du schnell genug capturen , komprimieren , übertragen , dekomprimieren und wieder anzeigen müsstest ...
auch mit der steuerung *gerade maus* dürfte es bei unterschiedlichen problemen zu skalierungs-fehlern kommen ...

daten-übertragung ist da eher das kleinere übel ...

wobei ich glaube kaum das du da mit RSA viel reißen wirst ... zeigt mir das du dich mit dem thema crypto noch nicht beschäftigt hast ... tipp : RSA-AES hybrid *zieh dir dazu mal funktionsweise von SSL rein*

prozessmanager wird auch schwer ... und sollte lieber vom OS selbst verwaltet werden *win : taskmanger , unix : kill*
auch kann ich mir nicht vorstellen das du mit java so viel gewallt ausüben könntest ... zu mal es sicher auch rechte-probleme geben wird

von der registry würd ich die finger lassen ... das kann man immer noch mit regedit machen ... was beides zum problem wird wegen der "live-übertragung"

alles in allem wird das mit java auch auf grund der VM ziemlich langsam ... da sollte man lieber was natives einsetzen ...

mein rat : sieh dir "TeamViewer" an ... bevor du die nächsten zwei jahre damit vergeudest vergeblich etwas eigenes zu basteln ...

 

[Poke]

Naja so schwer ist das alles garnicht zu realisieren, bin gerade dabei in C# etwas ähnliches zu realisieren, zumindest was Datei-Management, Registry und Prozesssteuerung angeht war das alles bisher kein Problem (Gesamtdauer: 2 Tage)

naja hab zwar keinen Chat, sondern nur Messageboxen, die dann jeweils beim anderen aufpoppen, aber ich sag mal das Prinzip wär auch nicht viel anders.
System-Infos wären auch kein Thema.
An den Screenshots und Mausübernahme werd ich gleich noch arbeiten

Zum Thema Firewall überwinden und verschlüsseln kann ich leider nichts beitragen, da es nur fürs LAN gedacht ist bei mir, wobei das verschlüsseln an sich auch kein Problem sein sollte, gibt es bestimmt schon für Java.

Und ja ich denk schon, dass UDP für diesen Fall sinnvoller wäre

 

[Bernd Hohmann]

alles in allem wird das mit java auch auf grund der VM ziemlich langsam ... da sollte man lieber was natives einsetzen ...

Kann ich nicht nachvollziehen. Es gab schon vor 12 Jahren von IBM ein in Java 1.1.7 geschriebenes Remote-Control Util was ohne native Routinen ausgekommen ist und richtig schnell war.

Comparison of Java Remote Desktop projects - Wikipedia, the free encyclopedia

Oder mal die Suchmaschine des geringsten Misstrauens nach "java remote desktop" oder "java desktop remote control" befüttern.

Bernd

 

[tuxedo]

@Bernd

Screenshot captured geht ohne eigene native Routinen AFAIK nur über die Robot-Klasse. Und die Sun/Oracle VM hat hier eine recht doofe Implementierung: Die Pixeldaten werden bei jedem Capture-Vorgang in ein neues Array geschrieben. D.h. das Array wird jedesmal neu erzeugt und anschließend irgendwann vom GC abgeräumt. Das kostet immens Zeit. Bei einem einzigen Screenshot fällt das nicht auf. Aber für eine "flüssige Desktop-Übertragung", selbst im lokalen Netzwerk taugt das leider nicht. Oder nur für sehr kleine Auflösungen oder Bildschirmausschnitte.

Hatte vor rund 2 Jahren das ganze mal mit einem Profiler untersucht. Nadelöhr war tatsächlich diese doofe Array-Geschichte. Wenn IBM hier eine eigene Vm nutzt und dort ggf. das mit dem Array "richtig" gemacht hat, dann wäre es möglich das tatsächlich in braucbbarer Geschwindigkeit zu realisieren. Aber so kommst du nicht großartig über 10-12fps bei heute üblichen Desktopgrößen.

Einen Umweg über Reflection, mit dem man immer ein und dasselbe Array reinstecken kann hab ich nicht hinbekommen. Durch final-Klassen und Co. hat Sun/Oracle sich viel Mühe gegeben das zu verhindern.

 

[Bernd Hohmann]

Hatte vor rund 2 Jahren das ganze mal mit einem Profiler untersucht. Nadelöhr war tatsächlich diese doofe Array-Geschichte. Wenn IBM hier eine eigene Vm nutzt und dort ggf. das mit dem Array "richtig" gemacht hat, dann wäre es möglich das tatsächlich in braucbbarer Geschwindigkeit zu realisieren. Aber so kommst du nicht großartig über 10-12fps bei heute üblichen Desktopgrößen.

Der Ansatz bei einem Remote-Desktop-Viewer ist es nicht, den kompletten Bildschirm zu übertragen sondern nur die geänderten Blöcke zu senden. Die Mausbewegungen werden isoliert betrachtet und fressen kaum Brot.

Bei Auflösungen von 2560x1600 kann immerhin noch mit 3-4fps gecaptured werden, beim ziehen ganzer Fenster oder wenn sich alles ändert bricht die Performance natürlich ein, aber das ist nach einem Update gelaufen und für den Notfall langt es.

Der Flaschenhals ist eher in der Bandbreite zwischen den Nutzern zu suchen, da werden je nach Farbtiefe und Auflösung im Ernstfall schnell mal 4-5MB per Frame (unkomprimiert) verschickt. Darum wird gerne bei der Übertragung die Farbtiefe reduziert.

Wirklich flüssig bekommt man das eh nur via RDP hin wo quasi die Windowmanager direkt kommunizieren und nach dem Austausch der Grafikelemente nur noch die Kommandos übertragen werden.

Bernd

 

[tuxedo]

Der Ansatz bei einem Remote-Desktop-Viewer ist es nicht, den kompletten Bildschirm zu übertragen sondern nur die geänderten Blöcke zu senden. Die Mausbewegungen werden isoliert betrachtet und fressen kaum Brot.

Na ganz blöd bin ich nicht. Klar wird nur ein Delta übertragen. Du scheint meine Kern-Aussage bei diesen zwei Sätzen aber ignoriert zu haben: Das Nadelöhr ist das capturen (schreibt man das so? sieht komisch aus). Denn um das Delta heraus zu finden, brauchst du mindestens einmal einen ganzen Bildschirm.

Bei Auflösungen von 2560x1600 kann immerhin noch mit 3-4fps gecaptured werden, beim ziehen ganzer Fenster oder wenn sich alles ändert bricht die Performance natürlich ein, aber das ist nach einem Update gelaufen und für den Notfall langt es.

Deine Aussage war, Zitat: "Es gab schon vor 12 Jahren von IBM ein in Java 1.1.7 geschriebenes Remote-Control Util was ohne native Routinen ausgekommen ist und richtig schnell war."

Und 3-4fps sind weit entfernt von "richtig schnell". Selbst wenn du nur 1920x1080 nimmst, und auch wenn du auf 2180x1024 runter gehst: "Richtig schnell" ist das dann auch nicht. Es wird akzeptabler, aber "schnell" ist ganz anders.

Der Flaschenhals ist eher in der Bandbreite zwischen den Nutzern zu suchen, da werden je nach Farbtiefe und Auflösung im Ernstfall schnell mal 4-5MB per Frame (unkomprimiert) verschickt. Darum wird gerne bei der Übertragung die Farbtiefe reduziert.

Bei steigenden Desktop-Größen ist beides ein Flaschen-Hals: Die "Dirty-Rectangle-Detection", sowie die Bandbreite, selbst wenn's komprimiert wird.
Hab 5 Jahre lang in einer Firma gearbeitet die es sich zur Aufgabe gemacht hat "Very Large Desktops" per Remote-Desktop, basierend auf dem VNC Protokoll zu übertragen. Mit Hilfe von Mirror-Treibern auf Grafiktreiberebene und GPU beschleunigter "Dirty Rectangle Detection" waren Desktops mit >3MegaPixel im lokalen Netzwerk "gerade so" akzeptabel. Und Deskrtops von >8MegaPixel waren da nicht selten.
Von dieser Performance ist die Robot-Klasse ganze Galaxien weit entfernt. Okay, heir geht's nicht um giganteische Desktops, aber was ich damit eigentlich sagen will: Mit der Robot-Klasse kannst du keinen heute aktuellen Standard-Desktop zufriedenstellend aufnehmen. 12fps sind wirklich hart an der Grenze des erträglichen. Alles darunter möchte man nicht wirklich bedienen müssen. Aber wenns keine andere Lösung gibt, sind 3-4fps natürlich besser als gar nichts.

[qupte]
Wirklich flüssig bekommt man das eh nur via RDP hin wo quasi die Windowmanager direkt kommunizieren und nach dem Austausch der Grafikelemente nur noch die Kommandos übertragen werden.

Bernd[/QUOTE]

Danke für die Lehrstunde. Aber das ist mir durchaus schon alles bekannt ;-) Ein Mirror-Treiber kann hier VNC aber auch immens beschleunigen, wenn man sonst die ganzen Parameter korrekt einstellt.

 

[Bernd Hohmann]

Wenn Du es so erwähnst: vor 12 Jahren war 800x600 die Standardauflösung des Desktop, dafür hat es anscheinend gelangt.

Und wir gehen hier von unterschiedlichen Voraussetzungen aus: ich nutze sowas wie VNC vorwiegend über irgendwelche Consumer-Internetleitungen und nicht im LAN. Wenn ich da auf irgendeine Maschine komme wo der User gerade sowas wie "www.ntv.de" ohne Werbeblocker auf hat, dann kann ich den Sekundenzeiger an der Uhr abmontieren und ansonsten bin ich froh, wenn das Bild wenigstens mit 2fps aktualisiert wird.

Für Vollbild-Pr0n im LAN ist awt.Robot nicht zu gebrauchen, das ist mir schon klar.

Bernd

 

[tuxedo]

@Bernd
Ich muss dich nochmal zitieren:

alles in allem wird das mit java auch auf grund der VM ziemlich langsam ... da sollte man lieber was natives einsetzen ...

Kann ich nicht nachvollziehen. Es gab schon vor 12 Jahren von IBM ein in Java 1.1.7 geschriebenes Remote-Control Util was ohne native Routinen ausgekommen ist und richtig schnell war.

Das ist irreführend. Erst behauptest du das ist alles kein Problem, geht "richtig schnell", und wenn man etwas nachbohrt kommt "bin ja froh wenn ich überhaupt 2fps zustande bekomme" und "vor 12 Jahren war ja auch 800x600 noch standard".

Ja, es war schnell, vor 12 Jahren. Aber "vor 12 Jahren" ist nun mal nicht "heute". Ergo bleibt nach wie vor der Rat: "da sollte man lieber was natives einsetzen ...".

 

[Bernd Hohmann]

Du hast recht. Weiterschaffen

Bernd