Cookie
Electronic Team, Inc. uses cookies to personalize your experience on our website. By continuing to use this site, you agree to our cookie policy. Click here to learn more.

Redirection des données d’un port série sur Telnet

Serial to Ethernet Connector vous permet d’utiliser le protocole Telnet RFC 2217 pour accéder à des périphériques série.
Essayer gratuitement
Période d'essai de 14 jours gratuits
La licence est disponible à partir de $259.95
Disponible pour

Accès à des ports série via Telnet RFC 2217

Serial to Ethernet Connector propose une solution d’accès à distance aux périphériques série tels que les appareils de surveillance industrielle compatibles avec le protocole Telnet. Telnet vous permet de vous connecter à des ports série distants comme s’ils se trouvaient sur votre ordinateur et de profiter de toutes les fonctionnalités des périphériques connectés. En utilisant Telnet, vous avez la possibilité d’utiliser des périphériques se servant de lignes de signaux pour transmettre des données telles que la rapidité de modulation, la parité et les bits d’arrêt. Ces périphériques comprennent notamment les modems et imprimantes utilisant le signal DCD (Data Carrier Detect) pour indiquer qu’ils sont prêts à être utilisés.
Un périphérique série partagé entre deux ordinateurs

Pensez à définir ces paramètres réseau lorsque vous utilisez Serial to Ethernet Connector :

Le protocole Raw ignore tous les paramètres et transmet les données directement du port série vers le réseau. En utilisant ce mode, vous devez configurer le port physique d’une certaine manière pour qu’il puisse fonctionner correctement. Vous pouvez établir plusieurs connexions à l’aide de ce protocole.
Telnet avec les extensions RFC 2217 permet au serveur et au client d’échanger les informations du port IP Telnet. Les modifications apportées au port local sont communiquées à l’ordinateur distant afin d’éviter tout problème de synchronisation des paramètres. Ce mode permet uniquement d’établir des connexions peer-to-peer.

Comment rediriger les données d’un port série sur Telnet

1
Installez le logiciel Serial to Ethernet Connector sur l’ordinateur auquel est connecté le périphérique série et sur l’ordinateur distant qui doit accéder à ses données.
Téléchargez et exécutez le programme d’installation
2
Créez une connexion serveur TSP sur l’ordinateur auquel est connecté le périphérique.
Pensez à choisir “Telnet” sur l’ordinateur local lorsque vous créez la connexion
3
Rendez-vous sur l’onglet “Connexions distantes" sur le deuxième ordinateur et cliquez sur le serveur précédemment créé pour établir une connexion. Attribuez un nom au port virtuel et cliquez sur “Créer” pour activer la connexion.
Sélectionnez “Connexion client” pour trouver le périphérique partagé
4
Vous pouvez à présent accéder au périphérique série sur Telnet en profitant des mêmes fonctionnalités qu’avec une connexion physique.
Vous pouvez modifier une connexion et afficher ses informations sur les deux appareils

Avis de nos clients

4.9 note globale, basé sur 372 utilisateurs revue
Utilisé par plus de 150 entreprises dans le monde entier
Daniele Besana
Ingénieur réseau
Serial to Ethernet Connector s’avère être la solution la plus efficace que j’ai pu essayer jusqu’à maintenant. La technologie de virtualisation de ports série proposée par ce logiciel permet d’éviter d’avoir à utiliser des cartes d’extension ou des ordinateurs supplémentaires. Cette technologie m’est particulièrement utile dans mon système de transmission de données car les interfaces RS 232 virtuelles sont la solution la plus simple pour l’accès à distance et la gestion des périphériques série sur le réseau.
Olivia Lane
Ingénieur en contrôle de la pollution
Dans notre laboratoire de contrôle qualité, nous utilisons des instruments spécialisés communiquant avec les ordinateurs via des ports série. Pour éviter d’avoir à déplacer et à recalibrer constamment notre matériel, nous avons décidé d’essayer de partager les appareils sur le réseau local. Serial to Ethernet Connector nous a permis d’y arriver facilement. Dorénavant, lorsque quelqu’un a besoin de se connecter à un appareil en particulier, il lui suffit de partager le port série sur l’Ethernet et d’y accéder à distance via un serveur terminal.
Stefan Mueller
Architecte solution chez Alpla
Serial to Ethernet Connector nous permet de connecter nos vieux appareils avec notre nouvelle application web. La principale raison qui nous a poussé à choisir Electronic Team est l’interface du logiciel. Elle semble bien plus intuitive et moderne que celles des logiciels concurrents. Grâce à Serial to Ethernet Connector, nous n’avons pas besoin de remplacer les appareils anciens connectés aux clients via des interfaces série et pouvons continuer à les utiliser avec la nouvelle solution.
Emma Davis
Programmeur en contrôle de processus
Serial to Ethernet Connector répond à tous nos principaux besoins. Cette solution fiable propose l’authentification par mot de passe et le chiffrement des données transmises. Ces fonctionnalités sont particulièrement importantes dans notre cas étant donné que nous travaillons avec des terminaux de point de vente et devons nous assurer que nos données soient sécurisées. Cette application nous permet d’accéder très facilement aux appareils de point de vente via des ports série virtuels partagés sur l’Ethernet.
James Meyer
Ingénieur performances
Les fonctionnalités de partage de ports COM de Serial to Ethernet Connector font désormais partie intégrante de notre logiciel de diagnostic de machines de plateformes pétrolières. Depuis que nos ingénieurs ont ajouté les fonctionnalités d’accès à distance dans notre système d’automatisation, le personnel de service peut détecter les problèmes affectant le fonctionnement du système de manière beaucoup plus rapide et efficace.
Jacob Williams
Ingénieur en communications
J’étais à la recherche d’un moyen pour rediriger un périphérique TAPI vers une session de bureau à distance Citrix XenDesktop. Étant donné qu’il semblait impossible de le connecter à un port COM virtuel sur XenDesktop, j’ai choisi d’utiliser une autre solution. Serial to Ethernet Connector m’a permis de rediriger mon périphérique TAPI sur l’Ethernet pour y accéder depuis ma machine virtuelle.
Claudio Corniani
Responsable ingénierie électronique chez PIUSI SPA (Italie)
Nous avons intégré les fonctionnalités de Serial to Ethernet Connector à notre matériel. Cela nous a permis de virtualiser un nouveau port série et de rediriger les communications vers le port Ethernet sans avoir à effectuer d’autre modification sur notre logiciel. Nous avons amélioré nos performances globales !

Questions fréquemment posées

Choisissez Telnet (RFC 2217) lorsque l’application distante doit contrôler ou surveiller le port lui-même — définir le débit en bauds, la parité, les bits de données/d’arrêt, basculer ou lire RTS/DTR/DCD, envoyer BREAK. RFC 2217 transporte tout cela à travers la liaison afin que les deux extrémités restent automatiquement synchronisées, sans coordination manuelle. Le coût est qu’il s’agit d’un mode pair à pair : un client par port partagé.

Choisissez Raw lorsque vous avez simplement besoin de transporter un flux d’octets et que les paramètres du port sont fixes ou que l’application n’y touche pas. Raw ignore les paramètres du port — vous configurez donc vous-même le débit/la parité du port physique sur l’hôte — mais il permet plusieurs connexions simultanées, ce que le mode Telnet ne permet pas. Règle rapide : l’appareil a besoin d’une configuration distante ou du contrôle des signaux → Telnet ; flux simple à débit fixe, ou besoin de le distribuer à plusieurs clients → Raw.

Réponse de Nikolai Svarachevsky · Développeur principal
En principe oui — la RFC 2217 est une norme publiée, donc SEC peut interopérer avec des implémentations tierces conformes, y compris des serveurs matériels de console/terminal de fournisseurs comme Digi, Lantronix et Moxa qui exposent l’option Telnet de contrôle de port COM, ainsi qu’avec des points de terminaison logiciels tels qu’un serveur Linux ser2net/pySerial. Cette interopérabilité est l’une des raisons de préférer le mode Telnet lorsque vous créez un pont vers un équipement non-SEC.

La réserve honnête : testez toujours sur banc l’association spécifique avant de vous y fier. Les implémentations diffèrent quant aux commandes RFC 2217 optionnelles qu’elles prennent en charge et à la rigueur avec laquelle elles suivent la spécification, de sorte qu’un serveur matériel donné peut gérer la négociation du débit en bauds mais pas une certaine commande de ligne de signal, ou inversement. Cela fonctionne généralement — mais « c’est une norme » ne remplace pas la confirmation que vos deux appareils particuliers s’accordent en pratique.

Réponse de Bohdan Miniv · Ingénierie QA
Les signaux de contrôle de flux sont représentés : RFC 2217 transporte l'état des lignes de contrôle (RTS/CTS et le mode de contrôle de flux) entre les extrémités, de sorte que la négociation matérielle est comprise par le protocole au lieu d'être ignorée comme en mode Raw. Pour la configuration et pour les appareils où le contrôle de flux relève d'une configuration correcte, cela fonctionne.

La limitation est la réactivité sur un réseau. Le contrôle de flux matériel existe pour ralentir un expéditeur rapide à l'instant où le tampon d'un récepteur se remplit — une réaction en temps réel mesurée en temps de caractère. Sur une liaison réseau, le changement de CTS doit revenir via TCP avec sa latence et sa mise en mémoire tampon, il peut donc ne pas arriver assez vite pour empêcher un dépassement sur un flux à haut débit. Sur un LAN à faible latence, c'est généralement acceptable ; sur internet, ne comptez pas sur le contrôle de flux matériel distant pour empêcher les dépassements de tampon sur un appareil rapide. Lorsque c'est possible, laissez le contrôle de flux agir localement au port physique et ne transportez que les données sur la liaison.

Réponse de Nikolai Svarachevsky · Développeur principal
Parce que la RFC 2217 négocie et contrôle les paramètres du port pour une seule session. Tout l’intérêt du mode Telnet est qu’un seul client connecté peut définir le débit en bauds, basculer les lignes de signal et lire l’état du port — et il n’existe aucun moyen cohérent pour que deux clients détiennent chacun cette autorité sur un même port physique en même temps. Si deux clients demandaient des débits en bauds différents, lequel l’emporterait ? Le protocole n’apporte aucune réponse, donc le mode est défini comme pair à pair.

C’est exactement pourquoi le mode Raw existe pour le cas un-vers-plusieurs : Raw n’implique aucun contrôle des paramètres du port, seulement des octets, il peut donc dupliquer le flux en toute sécurité vers de nombreux clients. Le compromis est l’autre face de la même pièce — Raw vous donne plusieurs clients mais aucun contrôle distant du port ; Telnet vous donne un contrôle complet du port mais un seul pair. Choisissez le mode qui correspond à votre besoin de contrôle ou de diffusion.

Réponse de Nikolai Svarachevsky · Développeur principal
Parce que la RFC 2217 est définie comme une option au-dessus de Telnet, qui fonctionne sur TCP — et elle dépend précisément des garanties que TCP fournit. Les commandes de contrôle de port (définir le débit en bauds, définir les lignes de signal) sont négociées dans la bande et reposent sur le fait que le flux arrive de manière fiable, dans l’ordre, les deux extrémités pouvant s’accuser réception mutuellement. C’est une conversation orientée connexion.

UDP n’offre rien de tout cela : pas de connexion, pas d’ordre, pas de garantie de livraison, pas d’accusé de réception. Une négociation qui suppose une livraison fiable et ordonnée ne peut tout simplement pas fonctionner sur un transport qui peut supprimer ou réordonner la commande même qui définit le débit en bauds. Les deux modes se séparent donc clairement selon le transport : la signalisation RFC 2217 relève de TCP, et UDP est réservé aux données brutes à sens unique. Si vous avez besoin du contrôle des signaux/paramètres, vous devez nécessairement utiliser TCP.

Réponse de Nikolai Svarachevsky · Développeur principal
Oui — cela fonctionne en mode Telnet comme en mode Raw. Les contrôles de segmentation des paquets de SEC incluent une option « envoyer lorsqu’un caractère avec un code donné est reçu », vous la réglez donc sur votre délimiteur de message et SEC conserve les octets entrants jusqu’à l’arrivée de ce caractère, puis transfère le message accumulé comme une unité. Cela permet de garder vos trames intactes sur un réseau qui, autrement, fragmenterait ou regrouperait le flux d’octets.

Cela s’associe aux déclencheurs connexes — conserver pendant une durée définie, ou vider lorsqu’un bloc atteint une taille choisie — et le compromis habituel s’applique : attendre le délimiteur ajoute délibérément un peu de latence en échange d’un découpage propre des trames. Pour un protocole orienté ligne (messages se terminant par CR/LF), c’est exactement le bon réglage ; pour un appareil qui nécessite la latence la plus faible possible sur chaque octet, laissez cette option désactivée.

Réponse de Nikolai Svarachevsky · Développeur principal
Serial to Ethernet Connector
Redirection de ports COM avec Telnet
Essayer gratuitement
Période d'essai de 14 jours gratuits
La licence est disponible à partir de $259.95
Disponible pour