Type de contribution : FAQ, ID de la contribution : 1235645, Date de la contribution : 19/10/1999
(0)
Évaluer

Comportement des processeurs de communication lors de transferts de données avec liaisons TCP sans RFC 1006

  • Contribution
  • Concerne le/les produits(s)

QUESTION:
A quoi faut-il veiller lors de l'utilisation de TCP sans RFC 1006 ?

REPONSE:
Le CP 343-1 TCP (6GK7 343-1EX00-0XE0 V5.0) et le CP 443-1 (6GK7 443-1EX02-0XE0) offrent dans leur version la plus récente un accès aux liaisons TCP sans RFC 1006.
Le comportement de cette interface est différent de celui d'une liaison TCP ISO. La différence réside dans le comportement de base de TCP : TCP est orienté flux de données et non pas messages. TCP n'a pas de mécanismes, qui donne une indication relative à la fin d'un message et au début d'un autre message. Cela signifie que le récepteur doit savoir quelle taille a le message et paramétrer le pointeur ANY du bloc Receive en conséquence.
Dans le cas d'une liaison TCP ISO, l'information de fin de message est garantie par l'ajout de protocole RFC 1006 "ISO Transport Service on top of TCP". Cela signifie toutefois qu'une communication ne sera possible qu'avec des systèmes qui supportent également RFC 1006.
On ne peut à cause de cela communiquer que de deux manières avec un TCP "pur" :

  1. On travaille avec une longueur de télégramme fixe, c'est à dire que l'émetteur et le récepteur travaillent avec une longueur de données prédéfinie. La longueur de message est ainsi toujours définie sans équivoque.
  2. On travaille avec une longueur de télégramme variable. Cela entraîne une charge plus élevée côté émetteur et côté récepteur car la longueur des données doit être renseignée dans les premiers octets. Lors d'une réception de données, le récepteur ne va chercher que les octets qui contiennent la longueur des données. Ceux-ci doivent être évalués dans le même cycle puis le nombre exact d'octets doit être lu sur le CP avec un autre appel Receive. C'est seulement à l'issue de ces requêtes que le télégramme est complètement transféré dans la CPU.
    Exemple:
    Un PC envoie entre 50 et 400 octets à un SIMATIC S7 équipé d'un CP443-1. Le programme du PC dépose lors de l'émission la longueur totale des données dans les quatre premiers octets. Puis les données accompagnées de cette information de longueur sont envoyées au CP. Seuls les quatre premiers octets des données reçues par le CP sont renvoyés dans un bloc de données de la CPU par le biais d'un appel Receive. Si l'indication de longueur est par exemple de 212, alors un deuxième appel (Receive) avec 208 octets est déclenché, qui va chercher les octets restants du télégramme. Il y a lieu de vérifier que la zone prévue pour la réception des données est toujours suffisamment grande, et que lors du deuxième appel les données issues du premier appel ne sont pas écrasées.
    Ceci n'est qu'un exemple. On peut lors du premier appel relire un volume quelconque de données, tant que celui-ci n'est pas supérieur à la longueur maximale de télégramme. Sinon le Receive attend jusqu'à ce que le volume de données renseigné soit effectivement déposé dans le buffer de réception du CP. Ceci peut nécessiter plusieurs télégrammes.

Attention au fait que sur le S7-300, seuls les FC50/FC60 peuvent être utilisés pour une liaison TCP, même si la longueur est inférieure à 240 octets.