Gegenfrage: wenn sich ein Drucker ganz einfach freigeben lässt, warum geht das nicht mit anderen Geräten bzw. Schnittstellen?
Weil sich jede der Schnittstellen unterscheidet, sowohl von Latenzzeiten die im Protokoll erlaubt sind als auch bzgl. anderer Merkmale. Der Drucker den du scheinbar freigibst, ist deswegen
nicht als Gerät freigegeben. Will heißen, auch wenn du vom Client aus Druckjobs senden kannst, hängt deswegen nicht an der einen Seite das Gerät wirklich dran, weil das nämlich schon oft genug deswegen nicht ginge, weil lt. Protokoll nur ein Rechner auf das Gerät zugreifen kann (hier der Druckserver).
Vielmehr wird der Client in die Lage versetzt einen für den freigegebenen Drucker verständlichen (Postscript, PCL ...) Job an den Druckerserver zu schicken, welcher dann die eigentliche Kommunikation auf der Ebene vornimmt auf der du deine Argumentation anbringst.
Falls du nicht ganz verstehst was ich meine, stell dir jetzt einen LPT-Dongle vor, der übers Netz freigegeben wird. Müßte ja deiner Argumentation nach gehen, da die Technologie vorhanden ist. Aber es handelt sich um eine andere Geräteklasse und die Lösungen die ich kenne waren alle bisher immer spezifisch auf eine Geräteklasse zugeschnitten.
Ein Terminalserver kann z.B. die serielle & paralle Schnittstelle des Clients benützen.
Was sind die höchsten Datenraten für einen LPT- oder
COM-Port? Und jetzt frag dich nochmal warum eSATA noch nicht übers Netzwerk existiert. Es ist einfach nicht sinnvoll, obwohl bei sowas wie USB sicherlich "Lizenzpolitik" auch eine Rolle spielen wird.
Man kann sogar Plug&Play-Geräte (also USB) umleiten.
Scanner, Kameras? Das muß recht neu sein, war mir nicht bewußt. Einerlei, rein vom Treibermodell her und so weiter, müßte sich das alles je nach Geräteklasse nochmal unterscheiden. Sprich: nur weil ein USB-Drucker geht, muß die USB-Kamera noch lange nicht gehen ...
Das heisst also die Technik des Umleitens ist da.
... eingeschränkt da, ja.