DeskStream 2 Release Candidate 1.8

**Andy**

Ja,
generell ist es jedem überlassen, Deskstream an seine Wünsche anzupassen.

Zitat

Ich möchte nur 1 Fenster sehen, welches auf dem Zielrechner läuft. Könnte man euer Tool dahingehend umbauen, das man einen Fenstertitel (-teil) des Servers mitgibt, und man dann im Client nur den Inhalt dieses Fensters bekommt, wenn es vorhanden ist ?

Hol dir das Handle des Fensters, ermittle Position, Höhe und Breite und passe diese 3 Werte im Bitblt im Server an.

Noch etwas in Sachen Mausclicks:
Zzt. werden linke und rechte Mausklicks in das Clientfenster an den Server weitergereicht.
Funktioniert das einwandfrei, oder werden bei euch nach einem Mausklick ab und zu komplette Frames (zu erkennen an einem Bild mit inversen Farben) ca 2-3 Sekunden nach dem Klick angefordert? Mit entsprechender ca. 1/2-sekündiger Wartezeit? Ich hatte dieses Phänomen vor kurzem auf einem Rechner, der nicht mir gehörte....zum Glück hatte ich etwas Zeit und habe festgestellt, dass einige Sekunden (und ca. 10-15 Frames) nach dem Mausklick "Müll" beim Client in der Pipeline war....seltsamerweise nur einige Bytes. Dies war schnell gefixt (mit 2 Zeilen) aber als ich einen Tag später zufällig das "alte" Script im Netzwerk laufen lies, gab es keinerlei Beanstandungen....scheint wohl eine/mehrere spinnende TCP-Verbindung(en) gewesen zu sein, aber wenn ihr dieses Phänomen auch schon mal beobachtet hättet, würde ich den Handshake anpassen....

Administrator

Zitat von "Andy"

Zzt. werden linke und rechte Mausklicks in das Clientfenster an den Server weitergereicht.
Funktioniert das einwandfrei, oder werden bei euch nach einem Mausklick ab und zu komplette Frames (zu erkennen an einem Bild mit inversen Farben) ca 2-3 Sekunden nach dem Klick angefordert? Mit entsprechender ca. 1/2-sekündiger Wartezeit?

Problem trat bei mir nicht auf.

Ich hab jedoch ein paar Vorschläge:

Könnte man die Auflösungsverhältnisse (4:3 ; 16:9 ; etc) beibehalten bzw. eine Checkbox dafür zu machen?
Dazu wären dann entweder 2 GUIs nötig oder eine GUI, die sich bei eingabe der IP (bzw. der Standart 127.0.0.1) automatisch die Auflösung holt und anzeigt.
Was zeigt der erste Zahlenwert der an dem Cursor fest ist an (links neben der FPS) ? -> Button zum deaktivieren, da selbst auch die FPS im Fenstertitel angezeigt werden
Eine möglichkeit, nach dem Zoom den Focus zu verschieben (Per Pfeiltasten; Inlay oder sonstwas), sodass man nicht jedesmal rauszoomen muss, um an eine andere Stelle zu kommen
Anstelle der sichtbaren Mausbewegung eine Schnellere. (MouseMove Speed nahe 1)
Unterstützung für ein 2Bildschirmsystem (Wieder ein Inlay oder Button zum wechseln? / Per Pfeiltasten bewegen)
Nachträglich die fenstergröße verändern (Per klick-ziehen am FensterRand)

Ich hoffe ich konnte euch (und letztendlich mir :P) ein paar Tips geben

Grüße

PS: Hier noch ein entdeckter Bug:
[Blockierte Grafik: http://www.abload.de/img/unbenanntfu9l.jpg]

Wie man sieht hinterlässt diese Mausanzeige einen kleinen Strich, wenn man diese nach oben bewegt

**Andy**

Hi,

Zitat

Könnte man die Auflösungsverhältnisse (4:3 ; 16:9 ; etc) beibehalten bzw. eine Checkbox dafür zu machen?

Ist für die nächste Version vorgesehen

Zitat

Was zeigt der erste Zahlenwert der an dem Cursor fest ist an (links neben der FPS) ? -> Button zum deaktivieren, da selbst auch die FPS im Fenstertitel angezeigt werden

Das ist ein Tooltip im Server, der die zzt übermittelte Anzahl der Bytes anzeigt. Such im Serverscript nach Tooltip und kommentier die Zeile aus....

Zitat

Eine möglichkeit, nach dem Zoom den Focus zu verschieben (Per Pfeiltasten; Inlay oder sonstwas), sodass man nicht jedesmal rauszoomen muss, um an eine andere Stelle zu kommen

schaumamal...die Bedienung mit dem Mausrad ist imho sehr schnell.

Zitat

Anstelle der sichtbaren Mausbewegung eine Schnellere. (MouseMove Speed nahe 1)

Einfach im Serverscript nach Mouseclick suchen (im case-zweig) und dort den Geschwindigkeitsparameter angeben, das hat auch den großen Vorteil, nun doppelklicks zeitnah weiterzugeben

[autoit]

Case "M" ;linke maustaste angekommen
MouseClick("left", $x, $y,1,0);klickt ohne verzögerung
Case "D" ;rechte maustaste angekommen
MouseClick("right", $x, $y,1,0)

[/autoit]

Zitat

Unterstützung für ein 2Bildschirmsystem (Wieder ein Inlay oder Button zum wechseln? / Per Pfeiltasten bewegen)

~~noch nicht vorgesehen^^~~...kann ohne weiteres eingebaut werden...

Zitat

Nachträglich die fenstergröße verändern (Per klick-ziehen am FensterRand)

gabs schon in einer der vorherigen Versionen, jedenfalls auf meiner Platte , kann eingebaut werden...

Administrator

Zitat von Andy

schaumamal...die Bedienung mit dem Mausrad ist imho sehr schnell.

Oder einfach unten und rechts zwei balken setzen, zum hin und herschieben

**Andy**

Zitat

Oder einfach unten und rechts zwei balken setzen, zum hin und herschieben

Gute Idee, mach das doch einfach!

**Sprenger120**

~~Update 1.6~~
-Seitenverhältnisse werden jetzt berücksichtigt (auch ausschaltbar)
-Interne Bugfixes

Administrator

ok. Ich nehme das "einfach" zurück. Ich hab ja auch großen Respekt vor eurer Programmierkunst
Aber hier als Tip, wenn du es brauchst Scrollbar

**Sprenger120**

Update 1.7

-Panning (wenn das Bild gezoomt wird kann man sich hin und her bewegen)
-Zoom kann mit den +,- Zeichen auf dem Ziffernblock gesteuert werden
-Interne Bugfixes (GetLongInf hat zu viele Daten gehohlt und dadurch die Komprimierungsfunktion abstürtzen lassen)
-Bildgröße ist jetzt veränderbar wenn man schon mit dem Server verbunden ist

DANKE für die über 500 Downloads

**Andy**

Hi,
das "Panning", also das Verschieben des vergrösserten Fensterinhaltes hat zzt. noch einen kleinen Schönheitsfehler.
Je nach Vergrösserungsfaktor kann es beim Verschieben mit den Pfeiltasten vorkommen, dass nicht nur in x- sondern auch in y-Richtung verschoben wird. Das ist infolge einer im Server schon verwendeten Funktion, so musste ich im Client nur 2 Zeilen ändern und konnte den Server unverändert lassen^^

Die Fenstergröße kann nun auch am Fensterrahmen verändert werden. Zoomen wie gehabt mit dem Mausrad oder mit den +- Tasten auf dem Numpad (gibts da Probleme/Vorschläge für Notebooks?) @Sprenger, ggf die Panning/Zoomtasten in die INI schreiben.

Aufgrund der laufenden Umgestaltung des Codes (er wird noch stark gekürzt und in den OnEventMode umgesetzt) arbeiten jeweils nur die "passenden" Clients und Server zusammen, d.h. ein Server einer früheren Version ist NICHT zu einem neuen Client kompatibel.

Der Handshake ist nun sehr konservativ und stabiler, die Latenz daher nicht optimiert, aber das sollte nicht weiter stören.

Bitte testen, ob es zu Fehlermeldungen kommt, ich hatte diese Version auf verschiedenen Rechnern im internen Netz und auch über Internet laufen ohne Fehlermeldungen. Bei Fehlern bitte auch die Bildschirmauflösung angeben.

Besonderer Dank geht an Raupi, bei dem ich übers Netz auch den Zwei-Bildschirmmodus testen durfte! (wobei die Leitung bei 1680x2x1050 Pixel x 4 Byte = 14MB fürs erste Bild (ohne Komprimierung)) schon geglüht hat^^. Allerdings lief die Steuerung auch über 2 Monitore sehr flüssig, auch Doppelklicks wurden durchgereicht.

Apropos Doppelklicks, bitte auch testen, wenn es nicht 100%ig funktioniert, müssen wir das per Message abfangen und ein Bit in der Nachricht an den Server setzen.

progandy

Das wird immer besser

Bei der Datenübertragung könnt ihr aber noch was rausholen denke ich. Wenn ich das richtig gesehen habe, sendet ihr die Binärdaten nicht direkt sondern in einer Stringrepräsentation. Dadurch wird die Datenmenge unnötig verdoppelt.

**Sprenger120**

Hi progandy,
Aaah Danke für die Info. Ich baue gerade alles auf Binäre Übertragung um. Das wird noch mal ordentlich Schub geben wenn nur die hälfte an Daten übertragen werden muss.

progandy

Zitat von Sprenger120

Hi progandy,
Aaah Danke für die Info. Ich baue gerade alles auf Binäre Übertragung um. Das wird noch mal ordentlich Schub geben wenn nur die hälfte an Daten übertragen werden muss.

Falls du ein paar Funktionen zum Senden/Empfangen von Paketen willst, die hab ich gerade gefunden (Ich weiß nicht, ob sie jemals getestet wurden)

Spoiler anzeigen

[autoit]

Global Enum $PT_KEEPALIVE, $PT_FULL, $PT_PARTIAL, $PT_SIZE ; Mal ein paar ausgedachte Pakettypen für DeskStream

[/autoit] [autoit][/autoit] [autoit]

; sendet ein Packet mit Typheader $iType und binären Daten $bData
; falls $fSize = True: Längenheader wird gesendet, sonst nicht
Func _Packet_Send($iSock, $iType, $fSize, ByRef $bData)
; Author: ProgAndy
Local $bHeader = Binary("0xCD")
If $fSize Then
$bHeader &= BinaryMid(BitOR($iType, 0x8000), 1, 2) & BinaryMid(BinaryLen($bData), 1, 4)
Else
$bHeader &= BinaryMid($iType, 1, 2)
EndIf
If Not IsBinary($bData) Then
Local $e = TCPSend($iSock, $bHeader & Binary($bData))
Else
Local $e = TCPSend($iSock, $bHeader & $bData)
EndIf
Return SetError(@error, @extended, $e)
EndFunc

[/autoit] [autoit][/autoit] [autoit]

; holt ein Packet vom Socket.
; $iType enthält den Typ-Header
; Rückgabe: Falls das Packet einen Längenheader hat, die Daten in dieser Länge,
; sonst @extended = 1 und leerer String (Daten müssen selber geholt werden)
Func _Packet_Recv($iSock, ByRef $iType, $fWaitForPacket=False)
; Author: ProgAndy
If TCPRecv($iSock, 1, 1) <> 0xCD Then
If Not $fWaitForPacket Then Return SetError(1,0,"")
Do
Sleep(0)
Until TCPRecv($iSock, 1, 1) = 0xCD Or @error
If @error Then Return SetError(2,0,"")
EndIf
$iType = _Packet_RecvData($iSock, 2)
If @error Then Return SetError(3,0,"")
$iType = Number($iType)
If BitAND($iType, 0x8000) Then
$iType = $iType-0x8000
Else
Return SetExtended(1, "")
EndIf
Local $iLen = _Packet_RecvData($iSock, 4)
If @error Then Return SetError(4,0,"")
$iLen = Number($iLen)
Local $bData = _Packet_RecvData($iSock, $iLen)
If @error Then Return SetError(5,0,"")
Return $bData
EndFunc

[/autoit] [autoit][/autoit] [autoit]

; ließt binöre Daten der Länge $iLen mit optionalem Timeout $iTimeout
Func _Packet_RecvData($iSock, $iLen, $iTimeout=-1)
; Author: ProgAndy
Local $bChunk, $bData = Binary(""), $iTim=0
Do
Sleep(0)
$bChunk = TCPRecv($iSock, $iLen)
If @error Then Return SetError(1,0,Binary(""))
If $bChunk = "" Then
If $iTimeout > 0 Then
If $iTim = 0 Then
$iTim = TimerInit()
ElseIf TimerDiff($iTim) >= $iTimeout Then
Return SetError(2,0,$bData)
EndIf
EndIf
Else
$iTim = 0
$bData &= $bChunk
$iLen -= BinaryLen($bChunk)
EndIf
Until $iLen = 0
Return $bData
EndFunc

[/autoit]

**Sprenger120**

Hi,

Zitat von progany

Falls du ein paar Funktionen zum Senden/Empfangen von Paketen willst, die hab ich gerade gefunden (Ich weiß nicht, ob sie jemals getestet wurden)

Nein Danke, hab mir schon selber was gebaut.

**Andy**

Hi,
@progandy, shame on me....
ich hatte vor ca. 2 Jahren per Wireshark festgestellt, daß AutoIt wohl "automatisch" den Bytemodus verwendet, wenn man einen "0x...."-String verwendet (beim Senden) . Jedenfalls war damals der Inhalt der Pakete identisch....
Das hatte ich im Hinterkopf und daher überhaupt nicht geschnallt, daß bei DeskStream ja garkein "0x...."-String gesendet wird, hätte ich diesmal per Wireshark gesnifft, hätte ichs sicher bemerkt
Daher vielen Dank für den Hinweis!

Hab die neuen Versionen umgeschrieben (string2binary/bynary2string are my friends^^), Sprenger wird sie sicher bald Online stellen! Waren nur 2-3 Zeilen zu ändern....=> doppelte Übertragungsrate jetzt!!!

**Sprenger120**

Update 1.8
Durch die Umwandlung der String Daten in das Binäre Format wurden die Übertragenden Daten halbiert. Das Bringt ~45% mehr Speed.

monkey

Ich würde es gerne mal testen habe jedoch nicht die Lust mir aus mehreren Foren die UDFs zusammen zu suchen.

Wäre es vielleicht möglich das du es mit den benötigten Ressourcen hoch lädst?

Würde mich sehr freuen

**Sprenger120**

Hi,
ähm es werden keine Externen UDF's verwendet!
Poste doch bitte mal deine Fehlermeldung.

monkey

Ah ich dachte dazu würde die Assembler UDF gebötigt.

Hatte den Maus-Courser über den Downloadlink gehalten und dann ist mir #include<assembleit.au3> aufgefallen, hatte jedoch nicht gesehen das es auskommentiert war

Dann noch in der Dankesliste
"Tomasz Grysztar für FASM
Ward für Embeddet FASM"

Alles OK getestet und läuft.

Sorry nochmal für den schon fast pöbelnden Post von eben

**Andy**

a propos Ward
Ward hatte HIER einige schöne Kompressionsverfahren in Assembler (auch 64Bit!) vorgestellt. Ich hab jetzt einiges probiert (im lokalen Netz) aber viel reißt es leider nicht!
Entweder sind meine Rechner zu lahm oder mein Netzwerk nicht schnell genug (wahrscheinlich beides) um Unterschiede zu merken...
Wer mag, kann ja mal ne Testreihe basteln. Es müssen dazu lediglich die Ward´schen Kompressions-UDF´s included werden, und im Client und Server die Kompressionsfunktion getauscht werden (im Client noch die folgende Zeile $len=@extended durch $len = binarylen($sdata) ersetzen).
/EDIT/
Beispiel:
Im Server #Include "LZMA.au3" hinzufügen und in der Zeile 222

[autoit]

$sString = _LZNTCompress(DllStructGetData($struct_string, 1)) ;binärstring fertig zum verschicken

[/autoit]

ersetzen mit

[autoit]

$sString = _LZMA_Compress(DllStructGetData($struct_string, 1)) ;binärstring fertig zum verschicken

[/autoit]

Im Client natürlich auch die Include einfügen und in Zeile 254

[autoit]

$sData = _LZNTDecompress($sData); daten dekomprimieren
$len = @extended ;länge der dekomprimierten Daten

[/autoit]

ersetzen durch

[autoit]

$sData = _LZMA_Decompress($sData); daten dekomprimieren
$len = binarylen($sdata) ;länge der dekomprimierten Daten

[/autoit]

das wars schon!
Schaut euch mal die Beispiele zur Kompression in Wards UDF an, bei einigen Funktionen kann man auch die Kompressionsstärke einstellen!
/EDIT/

Jetzt hängts eher noch am Ablauf des Protokolls, das war in den ersten Versionen wesentlich schneller, da der Server schon ein neues Frame berechnen konnte, während der Client parallel dazu sein Frame aus den übertragenen Daten extrahiert hat.
Zur Zeit ist das *hust* extrem langsam (alles nacheinander statt parallel)) gelöst, das synchronisieren von Client und Server steht aber ganz oben auf der ToDo-Liste.

Keine Ahnung, ob der OnEvent-Modus auch noch was bringt, oder ob der eingebaute "Delay" in GuiGetMsg() zur Zeit garnicht triggert....

**Andy**

Habe mal ein Beispiel in den vorigen Post editiert, wie man Wards Kompressions-UDF in Deskstream verwenden kann um noch ggf einiges an Geschwindigkeit rauszukitzeln.

So wie ich das sehe, nützen HOHE Kompressionsraten bei schnellen Rechnern (Client UND Server! ) und einer eher langsamen Leitung, bei langsamen Rechnern sollte man eher die Kompression niedriger einstellen.

Noch etwas in Sachen Portabilität:
Ich habe einige Demos für JavaScript und den Einsatz der JIT-Compiler bewundert, da ist mir die Idee gekommen, den DeskStream-Client als Javascript (oder ggf in Java direkt) zu implementieren.
Somit könnte man von jedem Browser aus eine Verbindung zum Server herstellen. Ihr könnt ja mal eure Meinung posten. Ich sage aber gleich, dass ich weder Java noch JS beherrsche, Code lesen (eingeschränkt) ja, Code schreiben nein Es würden also JS/Java-Programmierer gesucht....