Moin Moin!
Folge dem Link. Telnet ist deutlich mehr als ein Raw Socket.
Ich bin ihm Gefolgt, aber z.b. um eine Webseite zu machen muss ich auch nichts über das IP/TCP protokoll wissen, obwohl ich es nutze. Dachte das ist bei Telnet auch so.
Ist ja auch so. Nutze einen fertigen Telnet-Server und Dein Problem löst sich in Nichts auf.
Anders herum: Wenn Du einen Webserver selbst stricken willst, wirst Du auch nicht ohne die entsprechenden RFCs auskommen.
Sources für Telnet-Server gibt es reichlich, wenn Dir nichts besseres einfällt, geh zu debian.org und finde raus, woraus die ihren telnetd compilieren.
Der telnetd kann ein beliebiges Login-Programm ausführen, auch z.B. ein Ruby-Script, dass stumpf per stdin/stdout mit der Terminal-Emulation im telnet.exe kommuniziert, ohne auch nur einen CPU-Takt lang mit dem Telnet-Protokoll ringen zu müssen.
Also PuTTy schliesst aus, doofes GUI rumgepfusche...
Geht das auch in verständlichem Deutsch?
Sorry. Ich möchte nicht das meine Anwender davon abhängig sind eine Grafische Oberfläche zu verwenden. Davon abgesehen hasse ich "Tools" für minimale Aufgaben (Chaos pur) ... Aber es kann ja nicht jeder Linux haben xD
Du redest wirr.
Trotzdem bin ich der Meinung das es auch "raw" funktionieren sollte.
Tut's ja auch, wenn man erstens versteht, was telnet.exe treibt, und zweitens weiß, auf welche(s) Terminal(-Emulation) man schreibt. Wie schon lang und breit erklärt, hat telnet.exe zwei Teile: Telnet-Protokoll-Handler und Terminal-Emulation. Ersterer kann Einstellungen der Emulation ändern und mit dem Server darüber verhandeln. Die Emulation sorgt beispielsweise dafür, dass Du mit ein paar zusätzlichen Bytes im Datenstrom Farbe bekommst. Im Raw-Mode schaltest Du den Telnet-Protokoll-Handler aus. Damit verlierst Du einige Konfigurationsmöglichkeiten und mußt Dich mit mehr Details der Terminal-Emulation rumschlagen.
Mach übrigens nicht den Fehler anzunehmen, dass sich jeder Telnet-Client exakt gleich verhält. Selbst beim telnet.exe von Microsoft möchte ich nicht darauf wetten, dass der sich unter allen Umständen von Version zu Version identisch verhält.
Auf modernen Macs hast Du wahrscheinlich ein telnet mit GNU- oder BSD-Abstammung, wie auch bei den meisten anderen Unixen. Dort muß sich der Telnet-Client nicht um eine Telnet-Emulation kümmern, denn -- welche Überraschung! -- er läuft selbst in einer Terminal-Emulation. Typischerweise Linux-Konsole, BSD-Konsole, xterm, xterm-color, konsole aus KDE, xfce terminal, PuTTY, und noch ein paar andere. PuTTY wiederum (ja, Du wirst es nicht los!) bringt eine xterm-color-artige Terminal-Emulation mit, die wahlweise auf ssh, telnet, raw sockets oder COM-Ports aufsetzt -- hab ich ja bereits erklärt. Ob und was das ganze High-Tech-Spielzeug an Telnet-Clients mitbringt, wirst Du vermutlich auf die harte Tour herausfinden wollen. Das iPhone hat meines Wissens kein Telnet an Bord, dafür kann man dann zwischen 5 bis N "Apps" wählen, die alle mehr oder weniger gelungen 30 bis 50 Jahre alte Hardware emulieren.
Das wunderschöne am Raw-Mode ist, dass Dein Server absolut keine Ahnung hat, welche Terminal-Emulation am anderen Ende des Sockets läuft, wie groß die verfügbare Fläche ist, und welche Fähigkeiten das (emulierte) Terminal hat. Und es gibt keinen Weg, das herauszufinden. Außer, Du benutzt das Telnet-Protokoll.
Oh, noch etwas: Viele kommerzielle Firewalls sperren default-mäßig Telnet und viele andere Dienste, typischerweise sehen die Leute hinter der Firewall das Internet nur durch DNS-, HTTP- und FTP-Proxies. Telnet nach draußen gibt's nicht. (Denn damit kann man viel zu leicht richtig gute Tunnels durch die Firewall bauen ... *g*)
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".