Diskussion:Terminalserver

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Terminalserver“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Da steht:

• Die Verbindung des Remote-PC zum Terminalserver kann langsam sein (zum Beispiel ISDN oder DSL), denn es werden nur der Bildschirminhalt und Tastatur-, Maussteuerungsinformationen übertragen

Das erweckt nach meinem Verständnis eine falschen Eindruck. Diesbezüglich viel günstiger sind Client-Server-Anwendungen - da werden nur die Nettodaten zwischen Server und PC übertragen, den Bildschirmaufbau und die -steuerung erledigt der PC. Ein Beispiel dafür ist die SAP-Anwendung: Datenbank und Software laufen auf einem (oder mehreren) zentralen Server, auf dem PC läuft die Software sapgui.

Ich werde den Artikel in diesem Sinne korrigieren und ergänzen. -- tsor 15:21, 22. Dez 2004 (CET)

Ich selbst habe die Erfahrung gemacht, dass Terminalserver-Lösungen gerade Netzlast verringern können. Wenn das lokale Word die im Netz gespeicherte Datei öffnet und bearbeitet, muss die gesamte Datei zum PC übertragen werden. Bei der Terminalservr Lösung ist dies nicht notwendig. Die Datenmenge des Bildschirminhalts ist um einige geringer. Dieser Aspekt ist vor allem bei WAN-Verbindungen oder bei den Einwahlverbindungen nicht zu vernachlässigen. Mit der Richtigstellung bin ich nicht wirklich glücklich, denn sie verleugnet einen wesentlichen Aspekt, der bei vielen Firmen und Kommunen für den Einsatz der Technologie spricht. --Lyzzy 23:05, 25. Jan 2005 (CET)

Also ich muss Lyzzy zustimmen, denn genau jenes kriegen wir kurz vor der Fachinformatikerprüfung eingebläut. --fred 22:12, 19. Apr 2005 (CEST)

• Ich habe das mal geändert, bei den Nachteilen stand ein ziemlicher Unsinn (sorry). z.B. können mit Citix ca. 3 Anwender über eine ISDN Leitung arbeiten, macht das mal mit Client-Server Architektur.

Die meisten SAP-Anwendungen arbeiten in einem Terminal (!), (good old Times) das waren also die Terminalserver bevor es Mirosoft gab. Es ist also KEINE Client-Server Anwendung, lokal ist ein Terminal-Client installiert, der überträgt nur die (ASCII) oberfläche des Terminals, insoweit ist das natürlich schneller. Wenn das (ASCII) Terminal in einer Terminalserver-Session läuft, müsste die komplette GUI des Terminals übertragen werden. Allerdings benutzen auch die SAP Anwender Standard-Software .. in der Summe sind Terminalservices also die besser (schnellere) Lösung. Wer was anderes meint soll doch mal einen Windows-Client per 9600´er Handy-Verbindung laufen lassen ... mit Terminal-Services klappt das ! Csp 23:33, 22. Aug 2005 (CEST)

Habe...

... das "Rückkehr zur Mainframe-Architektur der 80er Jahre" raus genommen, war mir zu unsachlich an dieser Stelle. DidiM 11:49, 6. Mär 2006 (CET)

Vorteil: Backup

Hallo (Gast),

ich weiß nicht ob das evt. mit rein kommt. Die backup lösung eines Terminal Server ist um ein vielfaches einfacher, als jeden client einzeln zu sichern...

Irreführender Titel?

Also eigentlich hatte ich hier nicht die die Beschreibung eines Produktes einer bestimmten Firma erwartet, sondern sowas wie in der englischen Wikipedia. -- 217.17.202.235 21:50, 28. Sep. 2009 (CEST)

Denke ich auch. Hier wird kein Terminalserver, sondern die Windows Terminal Services (Remote-Desktop) beschrieben. Das hat mit einem Terminalserver aber überhaupt nichts zu tun.

Terminalserver sind eigentlich Geräte, welche Bildschirmarbeitsplätze (engl. Terminals) an verschiedene Computer vermitteln können. Auch der englische Artikel ist hier zu eng gefasst. Er geht davon aus, dass der seriell arbeitenden Arbeitsplatz mittels eines LANs über Ethernet weiter vermittelt wird. Das ist bei den heute erhältlichen Geräten wohl ausschließlich der Fall. Es gab davor aber auch Terminalserver, an welche die Rechner (oder auch Modems) mittels RS232 angeschlossen wurden. Nach dem Einschalten des Terminals wurde der Benutzer mit dem Terminalserver verbunden und konnte sich dann mittels geeigneter Eingabe (komplexere Kommandos oder einfach ein Rechnername) mit dem gewünschten Server verbinden lassen. -- 79.196.179.202 20:33, 11. Feb. 2010 (CET)

ohgottogott

Dieser Artikel ist eindeutig von Technikern geschrieben. Was machen denn die Hinweise auf M$ in dem Artikel? So ein allg. Artikel sollte auch nur die allg. Angaben zu Terminalservern beinhalten. Was ist das, welche Idee steckt dahinter. Fertig. Produkte kann man verlinken oder auf weiteren Artikeln dazu nennen. (nicht signierter Beitrag von 109.90.213.75 (Diskussion) 17:01, 1. Apr. 2013 (CEST))

keine Historie, sehr MS Terminalserver lastig

Habe mir den Artikel angesehen, mit kleinen Änderungen ist der nicht allgemeingültig zu machen, große Abschnitte der MS Terminalserver-Produktbeschreibung haben hier wenig Sinn und müssen raus. Die 30 Jahre Historie dieser Funktionen kommt praktisch gar nicht vor. Tja, und dann wird wohl ein (IT-)"Techniker" den Artikel umschreiben müssen, denn ich wüßte nicht, wer sonst das nötige Fachwissen dazu hätte (mit Grüßen an den "ohgottogott"-Vorredner). Werde das in den nächsten Tagen angehen -- Miwandinger (Diskussion) 16:19, 7. Sep. 2017 (CEST)

Telnet, Putty und Co

Telnet ist vergleiche beim Windows System unter C:\Windows\System32\drivers\etc\services eine Protnummer nach

Zitat "# This file contains port numbers for well-known services defined by IANA"

unter Unix (Linux) Systemen findet sich die Datei services im Verzeichnis /etc

Port 23/TCP

Putty ist nicht well-known trägt sich als eigenen Port dort ein. beide sind reiner Text, haben mit GUI nicht im Ansatz was zu tun.

beiden gemeinsam ist sie funktionieren auch mit der seriellen Schnittschtelle ohne TCP, Telnet, Putty z. B. um einen Switch oder Router (Cisco z. B.) mit entsprechender Schnittstelle konfigurieren zu können.

IBM 3270 eine IBM Terminal, das mit formatiertem Text (Farbe, blinken), und programmierbaren Ausgabefeldern arbeitet, ähnlich Terminals wie VT100 oder VT220

Entschuldigung, vergessen--Hugo (Diskussion) 22:01, 18. Sep. 2019 (CEST)

Nachteile fehlen bzw. sind als Vorteile aufgeführt:

- wesentlich mehr Netzwerkverkehr als bei eigenständigen Clients (X-Window System ausgenommen) - zentrale Verarbeitung, wenn Server überlastet arbeiten alle Clients langsam - zentrale Verarbeitung, wenn Serverwartung/Probleme kann niemand arbeiten (nicht signierter Beitrag von 2001:16B8:5C27:3300:603D:9624:19DD:833C (Diskussion) 08:51, 16. Mär. 2020 (CET))