Die technische Herausforderung bei der Sache besteht darin, dass serielle Kommunikation nie dafür vorgesehen war, über ein Netzwerk zu gehen, geroutet oder gar über das Internet übermittelt zu werden. Serielle Daten fließen in einem kontinuierlichen Strom von einem Gerät zum anderen, was Ethernet und TCP/IP bekanntlich nicht leisten. Ein Device-Server macht also weit mehr, als die physikalischen und elektrischen Verbindungen zu integrieren, sondern setzt auf Protokollebene an.
Er teilt die Daten in Pakete, gibt jedem Paket eine Zieladresse, nimmt das Paket in ein IP-Datagram, gibt diesem einen Header und Trailer. Dann sendet es dieses Paket entweder direkt zum Ziel oder zum Gateway. Die Device-Server kapseln also die
seriellen Daten in TCP- oder UDP-Pakete und transportieren sie auf diese Weise über das Netzwerk. Dies funktioniert bidirektional. Device-Server enthalten also einen TCP/IP-Protocol-Stack, Funktionen für Management aus der Ferne sowie je eine serielle und eine Netzwerk-Schnittstelle.
Doch auch mit dem Einsatz eines Device-Servers ist es nicht immer getan. Manche serielle Geräte erfordern einen ganz bestimmten PC zur Verarbeitung ihrer Daten und Informationen. Auch in diesen Anwendungsfällen ist der Device-Server Teil der Lösung. Eine Redirector-Software läuft dann aber zusätzlich auf dem entsprechenden PC. Diese Software nimmt die Signale des PCs, die für seinen COM-Port bestimmt sind, und leitet sie über den Netzwerk-Anschluss um. Über das Netzwerk erreichen sie die Netzwerk-Schnittstelle des Device-Servers. Die Redirector-Software sorgt also dafür, dass der PC glaubt, direkt mit einem lokalen Gerät per COM-Schnittstelle zu sprechen, obwohl das Gerät entfernt ist und über das Netzwerk angesprochen wird.