DeskStream 2 Release Candidate 1.8

Zitat

Nee die Bilddaten werden nur nicht mehr durch _LZNTCompress komprimiert sondern nur noch die reine Assembler Komprimierung.

Wenn man die Anzahl der unterschiedlichen Pixel bei den aufeinanderfolgenden (Video-)Frames mit 100% ansetzt, komprimiere ich im Schnitt nur durch meine "billige" (440 Byte) Quantisierung und Lauflängenkodierung (2 verschiedene) auf immerhin 30% der ursprünglichen Datenmenge! Mit etwas höherer Quantisierung kommt man locker auf 10%, da gibts bei Video aber schon leichte "Geisterbilder" und auch im Textmodus schon kleinere Farbverfälschungen.

Diese "komprimierten" Daten stampft _LZNTCompress() nochmal um ca. 20% ein. Leider berichtet Sprenger120 von sporadischen Fehlern(Abstürzen) bei dieser Funktion unter WIN7.
Da aber die Geschwindigkeit übers Netzwerk proportional zur Menge der übertragenen Daten sinkt, sind wir für jedes gesparte Bit dankbar!
Um jetzt _LZNTCompress zu ersetzen, habe ich mit einer Huffmann-Kodierung experimentiert und so ca. 20-30% eingespart. Leider nur "zu Fuss", und nicht in ASM, da gibts sicher fertige und schnelle Funktionen, damit ich nicht das Rad neu erfinden muss!

Aber wie schon weiter oben gesagt, für "normale" Fenster auf dem Desktop ist DeskStream bei weitem schnell genug! Wer Videos in Orginalgrösse streamen will/muss, soll halt ein dafür gebasteltes Programm benutzen.

Das ist doch nur eine Frage, wer Client und wer Server ist!
Beim Client brauchts kein Port-forwarding. Für den darauffolgenden Ablauf/Kommunikation ist das völlig irrelevant.
Also installiertst du den Client, welcher sich von jedem Rechner mit deinem Server (da muss dann natürlich Port-geforwardet sein) verbindet.
Denn "raus" wird nur extrem selten (personal firewall) geblockt. Zur allergrössten Not initialisiert man die Verbindung über Port 80(http), der sollte immer nutzbar sein.

Zitat

die beim Hilfesuchenden nur einen Doppelklick benötigt.

läuft bei mir bereits seit einigen Jahren völlig problemlos. Hilfeanfrage kommt per Telefon, ich verschicke eine e-mail, dort muss auf einen Link geklickt werden. Client-Programm wird heruntergeladen und gestartet (ggf UAC abnicken lassen) und verbindet sich mit meinem "Server" dank automatischer Namensauflösung. Nix IP^^. Dann startet die Remote-Hilfesession.
Ich habe diese Lösung gewählt, weil ein User genau deshalb anruft, weil er NICHT in der Lage ist, die "eingebauten" Remoteprogramme zu starten bzw. mit den seitenlangen Anleitungen nicht klarkommt. Ein unbedarfter Bekannter hatte nach einer Fehlkonfiguration sein komplettes Netzwerk ins Internet gestellt, incl. sämtlicher Freigaben auf ALLES (Dateien,Ordner, Drucker usw.). Nach 3 Tagen ging natürlich NICHTS mehr. Ganz und gar nicht lustig.

Zitat

Ist es nicht so, dass ich auf beiden per TCP/IP die IP-Adresse des anderen angeben muss?

nein, der Server braucht keine Adresse, der weiss, wo er wohnt^^.
Der sitzt nur irgendwo rum und wartet, dass irgendein PAKETkurier der Firma TCP (nicht UPS^^) an sein PORTal anklopft und sein Paket(Daten) abliefern will.
Da freut sich der Server, und gibt seine eigenen Daten dem Paketfuzzi wieder mit, der sie zum Client zurückträgt.
Der Client muss natürlich wissen, wo der Server wohnt und braucht somit dessen ADRESSE!

Weil aber haufenweise Paketkuriere herumschwirren, die dem Server irgendwelche unwichtigen Werbemitteilungen erzählen wollen, und der Server da absolut keinen Bock drauf hat, gibts VOR dem Server einen Rausschmeisser(Router), der nur die Kuriere durchlässt, die 1. die genaue Adresse des Servers wissen, und auch 2. die Hausnummer, die auf dem PORTal steht...
Der Rausschmeisser ist gewissermassen der Weiterleiter oder Filter der Nachrichten (Portforwarding im Router)

Der erste Parameter von TCPListen ist die IP von dir selbst bzw da wo der Server lauf draufen soll.

Parameter

IPAddr: Internet Protokoll "Punkt-"Adresse(IpV4) wie z.B. "192.162.1.1".

Zitat

Der Server braucht seine eigene IP, damit er weiß, auf welcher Netzwerkkarte er arbeiten soll. Ein PC kann ja mehrere Karten und IPs besitzen.

wenn du beim DeskStream-Client die Combobox aufmachst, ist neben deiner "eigentlichen" IP-Adresse auch noch mindestens eine andere, nämlich localhost 127.0.0.1 (eine "virtuelle" Netzwerkkarte, s. loopback)
Alle weiteren IP´s, z.B. von anderen Netzwerkkarten oder auch VM´s (so diese denn übers Netz ansprechbar sind) sind dort auch eingetragen.
Wie prog@ndy schon schrieb, nimmt der Server nur Anfragen an seine IP entgegen. Wenn du Deskstream auf einem Rechner testen willst, kompiliere den Server und starte ihn vor dem Client. Wenn beide localhost benutzen, funktioniert Deskstream einwandfrei. Genauso, wenn du bei beiden Scripten deine "richtige" IP einträgst, z.B. 192.168.4.100. Wenn du nun den Server auf deine IP einstellst, aber den Client auf localhost benutzen willst, funktioniert die Verbindung NICHT mehr! Obwohl doch beide auf dem selben Rechner arbeiten

Zitat

Der Client hatte die Server-IP eingetragen, der Server die Client-IP.

Der Server die Client-IP? Wieso DAS denn?
Starte den Server. Wähle im Server aus der Comboliste die Adresse, welche NICHT 127.0.0.1 ist. Das ist die Adresse des Serverrechners!
Und genau diese Adresse trägst du nun in den Client ein!

@Sprenger, wir sollten als Standardadresse im Server die erste NICHT-Localhost-Adresse angeben, vielleicht hifts^^

Zitat von MatthiasG

aber wie schickt der Server denn nun etwas an den Client zurück? Hat jemand freundlicherweise ein Snippet parat?

Zunächst einmal ein LINK und noch ein Link! Das sollte einiges klären...

Snippet brauchts nicht, wenn man kapiert hat, dass sobald der Server die Verbindungsanfrage des Clients angenommen hat, jeder der beiden als Sender per tcpsend() und Empfänger per tcprecv() arbeiten kann.

Hast du schonmal ein Telefon benutzt? Wenn das Telefon eingeschaltet auf dem Tisch liegt und WARTET, entspricht es unserem Server.
Wenn es klingelt, kannst du dir aussuchen, ob du das Telefongespräch annimmst oder nicht, genau wie der Server.
Wenn du das Gespräch annimmst und telefonierst (sprechen=tcpsend(), hören=tcprecv() ), ist es für die Verbindung völlig egal, wer dich angerufen hat und welche Rufnummer derjenige besitzt! Um mit dem anderen zu sprechen brauchst du dessen Telefonnummer nicht! Auch wenn die Rufnummer des Anrufers unterdrückt ist, klingelt trotzdem dein Telefon.

Gezoomt wird mit dem Mausrad im Clientfenster, dabei wird um die Position des Mauscursers herum zentriert!
Linke und rechte Mausklicks werden aus dem Clientfenster an den Server weitergereicht.

Auch wenn schon einige gefragt haben, NEIN, eine Tastaturübertragung egal in welche Richtung wird NICHT implementiert. Wer Interesse und reichlich Kleingeld hat, kann diese bei mir anfragen. Ich behalte mir wie üblich vor, Angebote in welcher Höhe auch immer, abzulehnen.