Hallo Zusammen, ich suche nach einer Möglichkeit, wie ich auf 1 PC von mehreren Arbeispläten aus zugreiffen kann. Genauer: Ich ziehe bald in eine neue Wohnung um. Ich möchte von jedem Zimmer aus auf einen Hauptrechner zugreifen können. 2x Arbeitsplatz, Wohnzimmer und Schlafzimmer. In jedem Raum soll es ein Monitor, Maus / Tastatur und USB Anschlüsse etc. haben, + Audio-Ausgänge. Der PC sitzt in einem der Arbeitszimmer. Es wird nicht gleichzeitig an den verschiedenen Plätzen gearbeitet. Wie realisier ich dies am einfachsten? Gibt es solche Geräte wo man in jedem Raum die Periphärie anschliesst und dann übers Netzwerk die Daten übertragen werden? Wie heissen solche Geräte, wonach soll ich Googeln? Bin ein ziemlicher Laie was Netzwerk & Co angeht, bin um jede Hilfe dankbar (Geräte, Stichworte nach denen ich Googeln kann etc. ) vielen Dank schonmal! Beste Grüsse, Markus
Du suchst nach KVM Switch. Wenn es über LAN gehen soll dann der Suche LAN hizufügen. Hier gibt es sowas zum beispiel. https://kvm-switch.de/de/
Kauf dir ein ordentliches mobiles Endgerät, dann kannst du sogar innerhalb der Zimmer mal die Sitzposition wechseln ohne separate Peripheriegeräte mitschleppen zu müssen.
@ Dennis vielen Dank für das Stichwort, ich schau mich mal um! :) @ Antoschka dies ist leider keine Option, der Hauptrechner steht bereits und die HW-Konfiguration lässt sich nicht soeinfach in ein mobiles Gerät integrieren (spezielle PCI-Karten / Audio-Interface). Trotzdem danke.
Tastatur/Maus/Monitor ist vergleichsweise einfach (Microsofts Remote Desktop, VNC, ...). USB wird schon deutlich interessanter, Audio wahrscheinlich auch. Wenn du auf diesem Weg nicht zum Experten werden willst, dann nimm ein Notebook und klemm es ggf unter den Arm.
markus schrieb: > Gibt es solche Geräte wo man in jedem Raum die Periphärie anschliesst > und dann übers Netzwerk die Daten übertragen werden? Solche Geräte sind i.d.R. teurer als jeweils ein kompletter PC pro "Arbeitsplatz".
A. K. schrieb: > dann nimm ein Notebook PS: ... mit jeweils einer Docking-Station an den Plätzen. Ist einfacher.
DS216 aktuelles Modell DS218 https://www.e-tec.at/frame1/details.php?art=253826&gclid=EAIaIQobChMIroHNmNaH3AIVGYfVCh1UrQgxEAQYASABEgIHrPD_BwE Alles wichtige an eigenen Daten drauf was vorher auf diversen PC, Läppis usw. rumflog. An den internen Router damit, über WLAN und LAN können alle Geräte(MAC iPAD Windows- und Linuxrechner) im Haus drauf zugreifen, sogar vom Internet, wenn ich will. Auf den Geräten läuft nur mehr gerätespezifische SW. Weiterer Vorteil die Platten in der DS sind gespiegelt. Zusätzlich ziehe ich halbjährlich Backups. Seither keine Daten verloren. ;) Namaste
mit Teamviewer kannst du komfortabel das gewünschte einrichten.
markus schrieb: > der Hauptrechner steht bereits und die > HW-Konfiguration lässt sich nicht soeinfach in ein mobiles Gerät > integrieren (spezielle PCI-Karten / Audio-Interface). Also nimm einen Notebook und gehe mit dem über Wlan/Lan per remote desktop auf deinen Hauptrechner. Usb kannst du da auch anschliessen und die Daten übertragen. Nur daß deine Programme auf dem hauptrechner den USB Anschluss an deinem Notebook "sehen" wird eher problematisch.
Wegstaben V. schrieb: > mit Teamviewer kannst du komfortabel das gewünschte einrichten. Das wär was für Fans der Cloud, mit gutem Internet-Anschluss. Denen es nichts ausmacht, dass der Kram über Server im Internet läuft, nicht lokal. ;-)
Hallo Zusammen, vielen Dank für die rege Beteiligung :) Wenn ich das richtig sehe, müsste es mit diesen Geräten realisierbar sein? 1x Transceiver am Hauptrechner: https://kvm-switch.de/de/sc-t-hkm01bt-2-kvm-over-ip-hdmi-usb-2-0-audio-rs232-ir-transmitter-bis-100m-ip-oder-cat.html 4x Receiver an den Arbeitsplätzen https://kvm-switch.de/de/sc-t-hkm01br-2-kvm-over-ip-hdmi-usb-2-0-audio-rs232-ir-receiver-bis-100m-inkl-ir-fernbedienung.html hat jemand Erfahrung mit diesen Geräten? Taugen die was? weitere Vorschläge für Geräte wie dieses? (KMV over IP) vielen dank! gruss Markus
markus schrieb: > @ Antoschka > dies ist leider keine Option, der Hauptrechner steht bereits und die > HW-Konfiguration lässt sich nicht soeinfach in ein mobiles Gerät > integrieren (spezielle PCI-Karten / Audio-Interface). Trotzdem danke. was stört dich am kostenlosen realVNC? braucht keine extra Hardware, läuft sogar auf einem Raspi (OK lahm) aber das Tempo macht ja der "Fernbediente" mit seiner Hardware, auf den Clienten will oder muss man vielleicht nicht TV sehen mit 60 FPS
Joachim B. schrieb: > markus schrieb: > was stört dich am kostenlosen realVNC? bis jetzt noch nichts, da ich noch nicht mal weiss was dies ist ^^ werde mich mal schlau machen darüber. mein kommentar bezog sich darauf, dass ich am liebsten 1 stationäres hauptgerät habe und kein mobiles.
A. K. schrieb: > Wegstaben V. schrieb: >> mit Teamviewer kannst du komfortabel das gewünschte einrichten. > > Das wär was für Fans der Cloud, mit gutem Internet-Anschluss. Denen es > nichts ausmacht, dass der Kram über Server im Internet läuft, nicht > lokal. ;-) https://community.teamviewer.com/t5/Knowledge-Base/Can-TeamViewer-be-used-within-a-local-network-LAN-only/ta-p/4618
markus schrieb: > Joachim B. schrieb: >> markus schrieb: >> was stört dich am kostenlosen realVNC? > > bis jetzt noch nichts, da ich noch nicht mal weiss was dies ist ^^ werde > mich mal schlau machen darüber. oder tightVNC oder ultraVNC
Wenn das verwendete Windows 10 nicht die kastrierte Heim-Version ist,
kann statt VNC auch das windowseigene RDP ("remote desktop") verwendet
werden. Das ist schneller, insbesondere seit den
Protokoll-Optimierungen, die mit Windows 8 eingeführt wurden.
Allerdings braucht man natürlich wiederum irgendein Gerät, auf dem man
den entsprechenden Client laufen lässt (Windows selbst liefert ihn mit,
mstsc.exe, aber es gibt auch RDP-Clients für Linux).
Es gibt auch sogenannte "Thin-Clients", das sind kleine stromsparende
PCs ohne Festplatte o.ä., auf denen eine korrespondierende Software
läuft. So etwas könnte gebraucht recht günstig zu bekommen sein; als
Neugerät ist ein Selbstbau z.B. auf Basis eines Intel NUC oder Gigabyte
Brix aber günstiger.
Joachim B. schrieb: > was stört dich am kostenlosen realVNC? > > braucht keine extra Hardware LOL, nur einen kompletten PC. Ausserdem musst du dem TO erst mal erklären, wie du mit RealVNC oder etwas ähnlichem eine USB-Schnittstelle so durchreichst, dass er an jedem Platz einen Stick oder sonstwas einstecken kann. KVM über VNC ist auch nicht geeigent, auch dafür braucht man einen Client-PC. Mir ist jedenfalls keine KVM-Over-Ethernet bekannt, bei der Tastatur usw. direkt ans Ethernet angeschlossen werden können. Natürlich sind die Vorstellungen des TO ziemlich unsinnig, aber so sind sie nun mal, und das ist eben die Frage, wie macht man das. Mir fällt da auch nichts ein ausser einem Server und Client-PCs an jedem Arbeitsplatz (natürlich furchtbar konventionell, sprich rückständig), daher melde ich mich auch zu dem Thema nicht mehr, das wird eh ohne Lösung versanden. Georg
Rufus Τ. F. schrieb: > RDP ("remote desktop") verwendet > werden. Das ist schneller, insbesondere seit den > Protokoll-Optimierungen, die mit Windows 8 eingeführt wurden. RDP war auch im Jahr 1998 schon ungefähr 42 mal schneller als das schnellste VNC. sogar über eine einzelne ISDN-Leitung.
Nun, auch VNC wurde weiterentwickelt und ist zwischenzeitlich benutzbar geworden. Apple verwendet das für seine "Remote Desktop"-Lösung.
georg schrieb: > Joachim B. schrieb: >> was stört dich am kostenlosen realVNC? >> >> braucht keine extra Hardware > > LOL, nur einen kompletten PC. och bei mir tun es einige PI unter 50,-€ > Ausserdem musst du dem TO erst mal > erklären, wie du mit RealVNC oder etwas ähnlichem eine USB-Schnittstelle > so durchreichst, dass er an jedem Platz einen Stick oder sonstwas > einstecken kann. war das das Ziel, dann erkläre wo du das liest! USB Anschlüsse kann auch heissen Maus und Tastatur ansonsten ist es kein Problem vom VNC Server aufs NAS zu speichern und am Client wieder abzuholen > KVM über VNC ist auch nicht geeigent, auch dafür braucht man einen > Client-PC. Mir ist jedenfalls keine KVM-Over-Ethernet bekannt, bei der > Tastatur usw. direkt ans Ethernet angeschlossen werden können. es gibt auch virtual USB für den PI damit kann ein abgesetzter PI übers Netzwerk USB Schnittstellen durchreichen als USB Server, sowas mache ich mit Sharkoon LANport um abgestzt über Netzwerk den ISP Prommer zu steuern. > Natürlich sind die Vorstellungen des TO ziemlich unsinnig, aber so sind > sie nun mal, und das ist eben die Frage, wie macht man das. Mir fällt da > auch nichts ein ausser einem Server und Client-PCs an jedem Arbeitsplatz > (natürlich furchtbar konventionell, sprich rückständig), daher melde ich > mich auch zu dem Thema nicht mehr, das wird eh ohne Lösung versanden. > > Georg besser so? VNC hat den Charme gegenüber RDP XRDP das alles was auf dem ServerPC passiert auf dem Monitor sichtbar ist Schalte ich die Webcam vom abgesetztem Client ein dann sehe ich das Bild auf dem Client und auf dem Server Monitor, oder eben ein Quellprogramm in der IDE kann beim Zimmerwechsel sofort weiterprogrammieren. Bei RDP und XRDP wird hinterrücks ein weiteres Fenster geöffnet welches auf dem Server nicht sichtbar ist, kann gut sein zur Zimmerüberwachung, nervt aber wer nach Zimmerwechsel weiterarbeiten will.
A. K. schrieb: > Das wär was für Fans der Cloud, mit gutem Internet-Anschluss. Denen es > nichts ausmacht, dass der Kram über Server im Internet läuft, nicht > lokal. ;-) Das kann man das auch nur fürs Heimnetz konfigurieren - über die lokale IP-Adresse. Was dabei noch außer Haus geht, weiß ich nicht. Und es gibt (zumindest) für Android auch Clients.
markus schrieb: > In jedem Raum soll es ein Monitor, Maus / > Tastatur und USB Anschlüsse etc. haben Joachim B. schrieb: > war das das Ziel, dann erkläre wo du das liest! Das ist halt wieder mal nur Widerspruch um des Widerspruchs Willen. Natürlich weisst du genau, dass der TO das gefordert hat, aber so hättest du ja keinen Grund für einen persönlichen Angriff. Es sind hier mal wieder die bekannten Chefpöbler des Forums unterwegs. Lassen wirs, an Beschimpfungen ohne jeden Grund bin ich schon lange nicht mehr interessiert. Du kannst mich auch ruhig noch weiter anpöbeln, wenn du dich dann besser fühlst, das ist für mich sowas von irrelevant. Georg
georg schrieb: > Du kannst mich auch ruhig noch weiter anpöbeln ich will dich überhaupt nicht anpöbeln, ich lese den Wunsch des TO nur anders er schrieb eindeutig die ganze nötige Hardware hängt am Server Rechner. Das nun USB am Client was anderes tun soll als Tastatur und Maus aufnehmen soll habe ich ncht interpretiert, offensichtlich du. Aber darum muss es doch keinen Streit geben oder (ausgenommen du willst streiten, ich aber nicht)
zB DELL WYSE Clients über RDP oder PCoIP. Wenn du allerdings zocken willst sieht es schon anders aus...
markus schrieb: > und USB Anschlüsse etc. haben, + Audio-Ausgänge Audio-Ausgänge auch noch, und was sich hinter etc verbirgt will ich garnicht erst wissen. Wünschen kann er sich das ja, aber darauf VNC vorzuschlagen geht halt weit am Problem vorbei. Wenn der TO nicht einsieht, dass er da einen PC als Arbeitsstation beschreibt, auch wenn es nur ein Raspi ist, ist ihm sowieso nicht zu helfen. Tastaturen oder USB-Buchsen*, die man direkt mit dem Ethernet verbindet gibt es eben nicht. Es ginbt zwar USB over Ethernet, aber das meint er bestimmt nicht und will es sicher auch nicht bezahlen. Auf jeden Fall kann man das Thema abhaken. Georg
Rufus Τ. F. schrieb: > Nun, auch VNC wurde weiterentwickelt Das ja. > und ist zwischenzeitlich benutzbar > geworden. Das nicht wirklich. Das kommt dir nur so vor, weil du halt heute typisch sehr viel mehr Bandbreite verfügbar hast. Es ist immer noch vielfach langsamer als RDP. Denn: RDP setzt in etwa das Konzept von X-Server um (nur halt auf Windows). D.h.: graphic primitives, font glyphs usw. brauchen nicht als Images übertragen werden. Das spart bei typischen Desktop-Anwendungen enorm Bandbreite. Mit RDP kann man ein Windows auch über eine ISDN-Leitung oder ein stark gestörtes 2,4Ghz-WLAN (heute leider der Normalfall) vernünftig bedienen. Versuch das mal mit einem aktuellen VNC...
Der Andere schrieb: > Nur daß deine Programme auf dem hauptrechner den USB Anschluss an deinem Notebook "sehen" wird eher problematisch. Das ist überhaupt kein Problem, da man es am Client konfigurieren kann. Es kann aber auch ein Vorteil sein, z.B. einen Lizendongle temporär dem fernbedienten Rechner zur Verfügung zu stellen. Joachim B. schrieb: > auf den Clienten will oder muss man vielleicht nicht TV sehen TV über RDP geht bei mir generell garnicht. georg schrieb: > Mir fällt da auch nichts ein ausser einem Server und Client-PCs an jedem Arbeitsplatz Es muß kein Server sein, ich fasse intern auch 'normale' Desktop-Windows per RDP an. Joachim B. schrieb: > Bei RDP und XRDP wird hinterrücks ein weiteres Fenster geöffnet welches auf dem Server nicht sichtbar ist, kann gut sein zur Zimmerüberwachung, nervt aber wer nach Zimmerwechsel weiterarbeiten will. Server ! Die MS-Desktop-OS lassen nur einen gleichzeitigen Nutzer zu, man übernimmt also immer die aktuelle Session. Beim Server kann man mehrere Sessions gleichzeitig fahren, aber mit /admin oder -console (je nach OS) auch eine bestehende übernehmen. Gemein ist, dass mehrere Sessions auf Windows-Servern persistent sind, also auch nach einem Reboot die Ressourcen belegt bleiben. Letztendlich schreit die Frage nach einem Kleinstrechner pro Zimmer, dazu sollte ein Raspberry locker genügen.
Manfred schrieb: > TV über RDP geht bei mir generell garnicht. da ich nur VNC nutze geht das sogar, reicht um den PI mit OSMC zu bedienen, nicht zum gucken wegen 5-10 FPS, auch die WEBcam wird übertragen zwar auch langsam aber mir genügt es.
Wer den ganzen Tag einen Rechner mit VNC fernbedienen will, muss schon ziemlich leidensfaehig sein. Bessere Alternativen wurden aber auch genannt: PCoIP.
Manfred schrieb: > Server ! Die MS-Desktop-OS lassen nur einen gleichzeitigen Nutzer zu, > man übernimmt also immer die aktuelle Session. Beim Server kann man > mehrere Sessions gleichzeitig fahren, aber mit /admin oder -console (je > nach OS) auch eine bestehende übernehmen. Gemein ist, dass mehrere > Sessions auf Windows-Servern persistent sind, also auch nach einem > Reboot die Ressourcen belegt bleiben. Du sprichst in Rätseln. Ich habe davon nicht gar so große Kenntnisse. Aber was der TO will, ist klassisch Server und Client. Wie es in kleinen und großen Firmen üblich ist. Ressourcen? Ist doch kein Thema. Auch im Privatbereich. Also man stöpselt seinen Mini-PC oder Laptop in jedem Zimmer an und hat sein eigenes Konto. Klar, W-LAN geht auch! Alles andere ist Mist.
Joachim B. schrieb: > nervt aber wer nach Zimmerwechsel weiterarbeiten will. Auch bei RDP (genau wie beim Linux-Äquivalent X2go) kannst Du eine Sitzung trennen und von einem beliebigen anderen Ort wieder aufnehmen und weiter arbeiten. Wenn Du natürlich wie mit deinem Webcam-Beispiel ein Programm lokal auf dem Client startest ist es natürlich nur auf dem Client. Auch bei VNC. Das ist ja auch logisch.
Bernd K. schrieb: > Wenn Du natürlich wie mit deinem Webcam-Beispiel ein Programm lokal auf > dem Client startest ist es natürlich nur auf dem Client. Auch bei VNC. ich hatte die Aufgabenstellung so verstanden und ich wünschte mir das auch. Aber Server! Denn der Server soll ja die angeschlossene Hardware nutzen! vielleicht verstehen wir uns auch miß, bei Synergy ist Server der PC der Maus und Tastatur besitzt Client der es nutzt Deswegen ist Server der PC für mich mit der angeschlossenen Hardware Server der PC der diese Hardware besitzt Client der es nutzt markus schrieb: > dies ist leider keine Option, der Hauptrechner steht bereits und die > HW-Konfiguration lässt sich nicht soeinfach in ein mobiles Gerät > integrieren (spezielle PCI-Karten / Audio-Interface). Trotzdem danke. ergo ist der Server derjenige mit der Hardware steht bei mir auch im Wohnzimmer und wird mit Client PC/PI anderorts genutzt, deswegen verstehe ich deinen Satz nicht! Bernd K. schrieb: > Wenn Du natürlich wie mit deinem Webcam-Beispiel ein Programm lokal auf > dem Client startest ist es natürlich nur auf dem Client. meine Clients haben keine Webcam, wozu auch wenn ich in Woohnzimmer schauen will?
Auch wenn es ein paar Nachteile hat.. Eine Möglichkeit wäre auch ein paar Steam-Links anzuschaffen. (gab es im Sale für 3€)
Joachim B. schrieb: > meine Clients haben keine Webcam, wozu auch wenn ich in Woohnzimmer > schauen will? Vielleicht versuchst Du vor dem Schreiben erstmal Deine Gedanken zu ordnen und nach dem Schreiben nochmal korrekturzulesen denn in dem Posting auf das ich mich bezog schriebst Du daß Du es auf dem Client startest und das Fenster deshalb nicht auf dem Server erscheint. Und das ist natürlich logisch. Diesbezüglich gibt es auch keine Unterschiede zwischen VNC und RDP: Was Du auf dem Server startest läuft auf dem Server und Du kannst es von jedem Client aus sehen und benutzen, was Du auf dem Client startest bleibt nur auf dem einen Client. Wenn Du darauf antworten willst dann versuch Dich bitte mal verständlich auszudrücken sonst geht das noch ewig so hin und her.
c-hater schrieb: > Es ist immer noch vielfach langsamer als RDP. Habe ich nirgends bestritten; und wenn Du genau gelesen hättest, hättest Du auch gesehen, daß ich RDP vorgeschlagen habe.
Joachim B. schrieb: > bei Synergy ist > Server der PC der Maus und Tastatur besitzt > Client der es nutzt Ziemlich schwachsinnige Auffassung, finde ich. Wobei ich zugeben muss, dass die Rollenzuordnung bei Anwendungen vom Typ "RemoteDesktop" wirklich nicht so ganz einfach ist. Da scheitern die klassischen Definitionen nämlich schlicht und ergeben: beide Seiten sind beides... Ich würde das eher in Richtung "Initiator" und "Responder" (wie bei VPNs) sehen, wobei dem Responder logisch natürlich die "Server"-Rolle zufällt, auch wenn der Initiator später selber für viele Aspekte der Verbindung auch wieder "Server" im Sinne der klassischen Definitionen ist. Die Grundidee ist einfach: wer will was von wem? Und die einzig logische Anwort ist: der, der was will, ist Client, womit für den Counterpart bloß die Rolle als Server bleibt. Das gilt auch dann, wenn der Client dann wiederum Serverdienste bereitstellen muss, um vom Counterpart das zu kriegen, was er haben will.
Manfred schrieb: > Es muß kein Server sein, ich fasse intern auch 'normale' Desktop-Windows > per RDP an. Ich meine ja auch nicht, dass das ein MS-Serversystem sein muss, das ist eh zu teuer, aber auch eine normaler PC kann funktionell als Server dienen (das gabs sogar schon bei MSDOS, wenn auch rumpelig). Bei Linux ist das eh kaum ein Unterschied, man installiert halt Samba, und ein NAS ist funktionell auch ein Server. Ob das dem TO genügt ist eine andere Frage. Wenn er z.B. in jedem Zimmer einen Audio-Anschluss braucht, muss er halt auch überall Lautsprecher und Mikrofone anschliessen. Was USB angeht, VNC und Konsorten reichen ja nicht USB weiter, sondern Tastendrücke und Mausbewegugen, egal woher die kommen, deshalb gabs das schon lange vor USB. Was der TO als USB-Anschluss haben möchte weiss hier keiner. Georg
c-hater schrieb: > Ziemlich schwachsinnige Auffassung, finde ich. Bei X ist es so, da ist das, was man auch "Terminal" nennen könnte, also das Ding, das den Monitor ansteuert, vor dem jemand sitzt, der Maus und Tastatur nutzt, der "Server", währenddem der PC, auf dem das Programm läuft, das dem "Terminal" mitteilt, was es wo darzustellen hat, als "Client" bezeichnet wird. Die andere Sichtweise, das "Terminal" als "Client" zu bezeichnen, hat sich recht überwiegend durchgesetzt. Da nennt man solche Geräte auch "ThinClient" ...
Rufus Τ. F. schrieb: > c-hater schrieb: >> Ziemlich schwachsinnige Auffassung, finde ich. > > Bei X ist es so, da ist das, was man auch "Terminal" nennen könnte, also > das Ding, das den Monitor ansteuert, vor dem jemand sitzt, der Maus und > Tastatur nutzt, der "Server", währenddem der PC, auf dem das Programm > läuft, das dem "Terminal" mitteilt, was es wo darzustellen hat, als > "Client" bezeichnet wird. Ich darf präzisieren: bei X11 ist es so, da is das Programm, welches Darstellungsbefehle bekommt um am Monitor die Pixel/Linien/Schriften/usw. darzustellen, das X11-Server Programm ist (en:server = de:dienender). Alle Programme welche dem X11-Server Darstellungsbefehle senden sind dessen Klienten Programme, Client programs und zwar unabhängig davon ob sie nun auf der selben Maschine wie der X11-Server laufen oder auf einem anderen vernetzten Computer. Es ist konsequent das gleiche wie bei Datenbanken: das Programm welche Daten hortet und auf Anfrage rausrückt, ist der DB-Server. Die die Anfragen stellende Programme sind die DB-Client Programme, genau wieder unabhängig davon ob nun auf der selben Maschine ausgeführt oder auf anderen. > Die andere Sichtweise, das "Terminal" als "Client" zu bezeichnen... ...ist Marketinggequatsche ;-) leider Eingebürgertes.
Mittlerer Datentechniker schrieb: > Es ist konsequent das gleiche wie bei Datenbanken: So, und nun stellst Du Dir mal einen dicken fetten PC vor, auf dem mehrere Programme mehrerer unterschiedlicher Benutzer gleichzeitig laufen. Die Bildschirmausgaben und Tastatureingaben der Benutzer erfolgen an minimalistischen kleinen PCs (oder sogar seriellen Terminals). Der X11-Definition zufolge sind das je ein Server pro Benutzer, und der dicke fette PC ist dann mehrere Clients gleichzeitig. Also ist auch ein serielles Terminal ein Server (daß das statt bunter Graphik nur etwas Text darstellt, dürfte für die grundlegende Betrachtung ziemlich irrelevant sein). Ja. Das klingt logisch. Irgendwie.
Bernd K. schrieb: > Vielleicht versuchst Du vor dem Schreiben erstmal Deine Gedanken zu > ordnen meine Gedanken sind geordnet und beziehen sich auf die Benennung der Programme, wenn man den Thread weiter folgt merkt man das es verschiedenste Definitionen für Server und Client gibt so das JEDER auch du versteht was er verstehen will, c-hater schrieb: > Wobei ich zugeben muss, > dass die Rollenzuordnung bei Anwendungen vom Typ "RemoteDesktop" > wirklich nicht so ganz einfach ist. Da scheitern die klassischen > Definitionen nämlich schlicht und ergeben: beide Seiten sind beides... genau! wer aber andere Sichtweisen NICHT zulässt kann nicht mitdiskutieren. Auf einem Clienten eine Webcam zu starten welche am Server hängt zeugt nun mal von Unverständnis. Bernd K. schrieb: > was Du auf dem Client startest bleibt nur auf dem einen Client. auf dem Client eine WEBcam starten die an Sever hängt? ziemlich verworren auch deine Rede :) georg schrieb: > Was der TO als USB-Anschluss haben möchte weiss > hier keiner. eben! RDP und XRDP fand ich brauchbar aber nicht für mich weswegen ich nur noch VNC und x11vnc nutze
Mittlerer Datentechniker schrieb: >> Die andere Sichtweise, das "Terminal" als "Client" zu bezeichnen... > ...ist Marketinggequatsche ;-) leider Eingebürgertes. Nein. Wenn auf irgendwelchen dabei beteiligten Protokollschichten zufällig der Client den Part des Servers übernimmt ändert das noch lange nichts an der grundsätzlichen Topologie: Zuerst baust Du als Client eine Verbindung zum Server auf, zum Beispiel per SSH. Alles was danach in dem Tunnel passiert sind Implementierungsdetails die den Anwender nicht interessieren müssen. Keiner nutzt in der Praxis nackte X11-verbindungen so daß er sich über solche Details Gedanken machen müsste, die werden immer über irgend etwas getunnelt und das ist es was der Endanwender zu sehen bekommt und wie es sich nach außen darstellt: Er startet zum Beispiel den X2go Client und verbindet sich mit einem X2go Server. Welche Richtungen dann dabei irgendwelche der zwei dutzend eingebetteten dreifach verschachtelten Low-Level Unterprotokolle haben die im Rahmen dieser Verbindung automatisch abgewickelt werden oder auch nicht interessiert ihn nicht die Bohne und soll es auch gar nicht. Der Client (Auftraggeber, Kunde) ist der der die Musik bestellt hat und der Server ist der der sie pflichtgemäß spielt. Wenn er dazu Rückfragen an den Auftraggeber hat die der Auftraggeber (oder einer seiner Untergebenen) beantworten muss damit das Geschäft abgewickelt werden kann werden dadurch mitnichten plötzlich die Rollen vertauscht in Bezug auf wer arbeitet für wen und in wessen Auftrag. Es mag sein daß der Dienstbote des Lieferanten (X11-client) den Dienstboten des Kunden (X11-server) im Zuge dieser einen Transaktion mal kurzfristig herumkommandieren darf und es mag auch sein daß der eine immer die Oberhand hat wenn sich x11client und x11server mal zufällig alleine auf dem Datenhighway treffen und keiner ihrer Herrn dabei ist aber das sind Implementierungsdetails die nicht nach oben dringen und die Herrschaften Kunden nicht interessieren. Am Ende wird im Rahmen des übergeordneten Protokolls geliefert was bestellt wurde und nur dadurch wird definiert wer hier Kunde und wer hier Lieferant ist.
> Der X11-Definition zufolge sind das je ein Server pro Benutzer, und > der dicke fette PC ist dann mehrere Clients gleichzeitig. Aber sicher. > Also ist auch ein serielles Terminal ein Server Klingonisch, ist aber so. (Genauso ein Display-server, halt nur Text, wenn auch in der Ära vor X11 zugegebenermassen Glass-TTYs tatsächlich nicht so bezeichnet wurden) > (daß das statt bunter Graphik nur etwas Text darstellt, dürfte für die > grundlegende Betrachtung ziemlich irrelevant sein). Exakt, habe ich nix dagegen. Definitiv gar nie wurden Glass-TTYs als Clients bezeichnet. Das Gerät, worauf ein klassischer X11-Server (+BootROM +TCP/IP-stack und kaum was anderes) drauf rennt nennt sich X11-Terminal. Z.b. aus der Serie TekXpress von Tektronix. Stell Dir vor: auf solcheinem Gerät sind dann Fenster zu sehen von beliebig vielen X11-Clients und das gleichzeitig! Für ein Multizeitzonen-Uhrencluster je ein xclock von einem VMS welches in Boston steht, von einem SunOS aus Kalifornien, von einem SINIX aus München, einem NeWS/OS aus Tokyo, usw. Ja das war eine tolle Zeit bevor die PCs wie eine Seuche über das Internet herfielen... %schwärm% Das was nicht passt, wir reden ja nur von Programme und deren Rollen, ist deine verkrustete Modellierung der Maschinengrösse: "dicken fetten" und "minimalistisch kleinen" zeugen von unflexiblem Denken ja gar von HW-Rassismus Deinerseits... Respektlosigkeit vor Alter und Klassischer EDV-Bildung obendrein auch noch. [Mod: Persönliche Beleidigung entfernt]
c-hater schrieb: > Joachim B. schrieb: > >> bei Synergy ist >> Server der PC der Maus und Tastatur besitzt >> Client der es nutzt > > Ziemlich schwachsinnige Auffassung, finde ich. Das liegt nur daran, dass viele im Hinterkopf haben, dass der Server immer das ist, was weit weg vom Benutzer ist. Aber eigentlich ist er das, was einen Dienst anbietet. Der Client ist das, was den Dienst benutzt. Und das ist ganz unabhängig davon, vor welchem von den beiden der Benutzer hockt. c-hater schrieb: > Die Grundidee ist einfach: wer will was von wem? Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der Server stellt diese Information zur Verfügung.
Wenn es nicht Enterprise Grade sein muss schau dir mal SteamLink an (wobei die Hardware wohl momentan durch eine Android App ersetzt wird, also evtl brauchst du jeweils eine Android Box + gratis App). Sollte eine weitaus bessere Performance abliefern als VNC da ausgelegt auf geringe Verzögerung und hohe Auflösungen.
Rolf M. schrieb: > Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf > Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der > Server stellt diese Information zur Verfügung. Diese Sichtweise lässt sich ebenso gut umdrehen und das passiert auch. Tatsächlich ist das schlicht eine Frage, wer mit wem Verbindung aufnimmt. Das X11 Netzprotokoll definiert das Terminal als Server, denn das Terminal stellt einen Port zur Verfügung und der zentrale Rechner nimmt damit Verbindung auf. Bei RDP und VNC ist das andersrum, d.h. der zentrale Rechner stellt den Port zur Verfügung, und der PC mit dem User davor nimmt damit Verbindung auf. Bei RDP nennt sich der zentrale Rechner auch Terminal-Server, weil er für potentiell mehrere Terminals den Server spielt.
Rolf M. schrieb: > Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf > Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der > Server stellt diese Information zur Verfügung. dann stimmt doch alles wieder Ein Gerät ist Server mein PI mit Webcam, alle anderen die es nutzen sind Clients (VNC) mein USBlanport 400 Sharkoon, alle anderen die abgesetzt USB nutzen sind Clients (eigener USB Treiber) mein PC mit Maus und Tastatur, alle anderen die es nutzen sind Clients (Synergy) ich weiss nicht mal warum das angezweifelt wurde! und beim TO ist es doch genauso, er möchte abgesetzt vom Server dessen Hardware nutzen, also alles was an Hardware am Compi hängt also stellt dieser den Server dar, die abgesetzten Nutzniesser sind Clients.
Rolf M. schrieb: > Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf > Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der > Server stellt diese Information zur Verfügung. Nein, im Fall Terminalserver oder X2co oder VNC oder RDP ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus! Wer der Server ist sieht man klar daran wer diesen Dienst anbietet. Wenn auf irgendeiner unteren Protokollschicht im Detail und ganz für sich allein betrachtet zufällig die Anfragen immer von der anderen Seite kommen und somit für diese abgegrenzte Unteraufgabe die Rollen Client/Server zufällig vertauscht sind stellt das noch lange nicht die Rollen von Client und Server im Gesamtzusammenhang dieses Dienstes und dieser Verbindung in Frage.
Bernd K. schrieb: > stellt das noch lange nicht die > Rollen von Client und Server im Gesamtzusammenhang dieses Dienstes und > dieser Verbindung in Frage. M.a.W: Was auf Netzwerkebene ein Server ist, kann auf Anwendungsebene ein Client sein, und umgekehrt. Und auf Anwendungsebene ist dann eben ein X-Server ein Client.
A. K. schrieb: > M.a.W: Was auf Netzwerkebene ein Server ist, kann auf Anwendungsebene > ein Client sein, und umgekehrt. Und auf Anwendungsebene ist dann eben > ein X-Server ein Client. Im Falle von Terminalserver ist sowohl aus Anwendungsebene als auch auf Netzwerkebene der Fall daß der Anwendungsserver auch der Netzwerkserver ist. Zum Beispiel ist es auf Netzwerkebene meist SSH über welches das abgewickelt wird, bei Windows ist es RDP und auch da ist der Anwendungsserver der Netzwerkserver. Auch die Namensgebung der beteiligten Softwarekomponenten lassen keinen Zweifel daran. Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle dringen in keinster Weise nach außen in Erscheinung und müssen also weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es benutzt wird und wie er sein Netzwerk konfigurieren muss.
Bernd K. schrieb: > Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle > dringen in keinster Weise nach außen in Erscheinung und müssen also > weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es > benutzt wird und wie er sein Netzwerk konfigurieren muss. Yep. Beim X11 wechseln Server und Client die Rollen, sobald man sie nicht mehr nativ über Netz betreibt, sondern über SSH. ;-)
A. K. schrieb: > Beim X11 wechseln Server und Client die Rollen, sobald man sie > nicht mehr nativ über Netz betreibt Nein. Sobald man sie tunnelt ist es für das äußere Erscheinungsbild des Tunnels nicht mehr relevant was die im Innern desselben treiben.
Bernd K. schrieb: >> Beim X11 wechseln Server und Client die Rollen, sobald man sie >> nicht mehr nativ über Netz betreibt > > Nein. Sobald man sie tunnelt ist es für das äußere Erscheinungsbild des > Tunnels nicht mehr relevant was die im Innern desselben treiben. Ohne Tunnel (nativ) verbindet sich die X-Anwendung direkt mit dem Terminal. Hier ist also das Terminal der Server. Deshalb wird ein solches Terminal traditionell auch als X-Server bezeichnet. Diese Bezeichnung ist fixiert, es sei denn man schreibt die Geschichte der letzten Jahrzehnte um. Mit Tunnel verbindet sich das Terminal mit dem Rechner, auf dem die Anwendung läuft. Das Terminal verbindet sich also mit einem SSH-Server. Die Anwendung verbindet sich per X-Protokoll dann mit dem Ende des SSH-Tunnels auf dem gleichen Rechner, auf dem die Anwendung läuft. Die Frage, wer da nun Client und Server ist, abhängig davon wo genau man nun hinsieht, führt also direkt ins Absurde. Oder wie gut klingt es, wenn ein X-Server sich mit einem SSH-Server verbindet, damit der X-Client (die Anwendung) auf dem Server mit dem Client (dem Terminal) kommunizieren kann? ;-)
A. K. schrieb: > Bernd K. schrieb: >> Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle >> dringen in keinster Weise nach außen in Erscheinung und müssen also >> weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es >> benutzt wird und wie er sein Netzwerk konfigurieren muss. > > Yep. Beim X11 wechseln Server und Client die Rollen, sobald man sie > nicht mehr nativ über Netz betreibt, sondern über SSH. ;-) Zur weiteren Bespaßung: $ man xnest
A. K. schrieb: > Die Frage, wer da nun Client und Server ist, abhängig davon wo genau man > nun hinsieht, führt also direkt ins Absurde. Ein speziell ausgezeichneter Ort von all den Orten wo man hinsehen könnte wäre "das Gesamtgebilde von außen betrachtet"
Mittlerer Datentechniker schrieb: > A. K. schrieb: >> Bernd K. schrieb: >>> Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle >>> dringen in keinster Weise nach außen in Erscheinung und müssen also >>> weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es >>> benutzt wird und wie er sein Netzwerk konfigurieren muss. >> >> Yep. Beim X11 wechseln Server und Client die Rollen, sobald man sie >> nicht mehr nativ über Netz betreibt, sondern über SSH. ;-) > > Zur weiteren Bespaßung: > $ man xnest Ich gehe mit und erhöhe um: $ man nxproxy
Bernd K. schrieb: > Rolf M. schrieb: >> Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf >> Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der >> Server stellt diese Information zur Verfügung. > > Nein, im Fall Terminalserver oder X2co oder VNC oder RDP Sehr kreativ, wie du den Fall, auf den ich mich bezogen habe, aus dem Zitat gestrichen und einfach durch andere, zu denen meine Aussage nicht mehr passt, ersetzt hast. Hier nochmal das Orignal: c-hater schrieb: > Joachim B. schrieb: > >> bei Synergy ist Server der PC der Maus und Tastatur besitzt >> Client der es nutzt > > Ziemlich schwachsinnige Auffassung, finde ich. Und darauf habe ich geantwortet. Bernd K. schrieb: > ... ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem > Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus! Ist er das? Würdest du die Aufgabe von VNC in der Bereitstellung von Rechenzeit sehen? A. K. schrieb: > Bernd K. schrieb: >> stellt das noch lange nicht die >> Rollen von Client und Server im Gesamtzusammenhang dieses Dienstes und >> dieser Verbindung in Frage. > > M.a.W: Was auf Netzwerkebene ein Server ist, kann auf Anwendungsebene > ein Client sein, und umgekehrt. Und auf Anwendungsebene ist dann eben > ein X-Server ein Client. Nein. Die Anwendung gibt dem X-Server Befehle zur Darstellung von graphischen Elementen, die dieser ausführt. Und sie gibt ihm Befehle, um Events abzuholen, die z.B. von Tastatur und Maus angekommen sind. Was Client ist und was Server, bezieht sich übrigens für mich nicht unbedingt darauf, wer die Verbindung aufbaut, sondern darauf, wer die Befehle gibt (Client=Kunde) und wer sie ausführt (Server=Diener). Meist baut der Client die Verbindung auf, aber muss er nicht zwangsweise. Bernd K. schrieb: >> Zur weiteren Bespaßung: >> $ man xnest > > Ich gehe mit und erhöhe um: > $ man nxproxy $ man xpra
Rolf M. schrieb: > Bernd K. schrieb: >> ... ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem >> Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus! > > Ist er das? Würdest du die Aufgabe von VNC in der Bereitstellung von > Rechenzeit sehen? In letzter Konsequenz ja. Und um Deine Frage die Du dennoch gestellt hast vorweg zu nehmen fügte ich ja in weiser Voraussicht noch "in Form einer Desktop Sitzung" hinzu. Es stellt also die Möglichkeit der Benutzung einer entfernt ausgeführten Software bzw. Desktopumgebung zur Verfügung, also mit anderen Worten die Benutzung von an entferntem Ort befindlicher Rechenzeit zu ermöglichen. Genau das tut es.
Bernd K. schrieb: > Rolf M. schrieb: >> Bernd K. schrieb: >>> ... ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem >>> Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus! >> >> Ist er das? Würdest du die Aufgabe von VNC in der Bereitstellung von >> Rechenzeit sehen? > > In letzter Konsequenz ja. Und um Deine Frage die Du dennoch gestellt > hast vorweg zu nehmen fügte ich ja in weiser Voraussicht noch "in Form > einer Desktop Sitzung" hinzu. Es stellt also die Möglichkeit der > Benutzung einer entfernt ausgeführten Software bzw. Desktopumgebung zur > Verfügung, also mit anderen Worten die Benutzung von an entferntem Ort > befindlicher Rechenzeit zu ermöglichen. Genau das tut es. Naja, für mich ist Client/Server eine Art der Kommunikation. Ich sehe den Zweck der Kommunikation bei VNC darin, Bildschirminhalte und Tastatur- und Mauseingaben zu übertragen und nicht in der Bereitstellung von Rechenzeit. Das macht das Betriebssystem des Rechners, nicht VNC.
Rolf M. schrieb: > Ich sehe > den Zweck der Kommunikation bei VNC darin, Bildschirminhalte und > Tastatur- und Mauseingaben zu übertragen Das selbe also wie RDP und X2Go: Die Möglichkeit mit lokaler Tastatur, Maus und Bildschirm über Programme auf einem entfernten Rechner zu verfügen. Das ist genau das was ich gesagt habe, nur mit anderen Worten. Vielleicht liegt es daran wie man seine eigene Rolle vor dem Bildschirm begreift: Ich empfinde mich als aktiv Handelnden, der Computer reagiert auf meine Eingaben. Somit reagiert auch der entfernte Computer auf meine Eingaben und ich verfüge über ihn. Andere mögen es eher so empfinden daß sie vorwiegend konsumieren und auf Eingabeaufforderungen des Computers oder des entfernten Computers reagieren. Die einen benutzen den Computer, die anderen lassen sich von ihm benutzen, so mutieren sie vom Master zum Slave.
„... Ich empfinde mich als aktiv Handelnden, der Computer reagiert auf meine Eingaben. Somit reagiert auch der entfernte Computer auf meine Eingaben und ich verfüge über ihn. Andere mögen es eher so empfinden daß sie vorwiegend konsumieren und auf Eingabeaufforderungen des Computers oder des entfernten Computers reagieren. Die einen benutzen den Computer, die anderen lassen sich von ihm benutzen, so mutieren sie vom Master zum Slave.“ Nachdem nun die Gefühlswelt geklärt ist , würde ich den nächsten Schritt machen und überlegen ob dann auf dem entfernten und Deinen „aktiven“ Befehlen wartenden Computer - ein Betriebssystem wie Windows Deinen Ansprüchen wirklich genügt ;-)
Walter K. schrieb: > Windows Na endlich! hab schon gewartet wann der erste endlich den obligatorischen und immerwährenden W... vs L... Streit vom Zaun bricht. Hat ja lange genug gedauert!
Bernd K. schrieb: > Walter K. schrieb: > Windows > > Na endlich! hab schon gewartet wann der erste endlich den > obligatorischen und immerwährenden W... vs L... Streit vom Zaun bricht. > Hat ja lange genug gedauert! Wieso L... ? Ich empfehle MacOS oder FreeBSD oder openBSD - also unixoide Betriebssysteme! Linux gehört da nicht wirklich dazu ;/)
Hat schon jemand bemerkt, dass der Kasper, der den Thread eröffnet hat, sich zuletzt zwei Stunden nach Eröffnung beteiligt hat, am 05.07. 13:16?
Walter K. schrieb: > Wieso L... ? Mit ist das schon öfters aufgefallen., Es gibt inzwischen einige Leute, die so empfindlich auf Linux-vs-Windows-Threads reagieren, dass sie gar nicht merken, dass sie die ersten sind, die das erwähnen und das damit selbst erst zum Thema machen.
Manfred schrieb: > Hat schon jemand bemerkt, dass der Kasper, der den Thread eröffnet hat, > sich zuletzt zwei Stunden nach Eröffnung beteiligt hat Von den ersten, noch qualifizierten und konstruktiven Antworten wollte er ja nichts wissen, und im weiteren Verlauf hat er auch nichts Erhellendes versäumt. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.