FR2719681A1 - Interfaces de canal améliorées pour des canaux d'entrée/sortie d'ordinateur. - Google Patents
Interfaces de canal améliorées pour des canaux d'entrée/sortie d'ordinateur. Download PDFInfo
- Publication number
- FR2719681A1 FR2719681A1 FR9505303A FR9505303A FR2719681A1 FR 2719681 A1 FR2719681 A1 FR 2719681A1 FR 9505303 A FR9505303 A FR 9505303A FR 9505303 A FR9505303 A FR 9505303A FR 2719681 A1 FR2719681 A1 FR 2719681A1
- Authority
- FR
- France
- Prior art keywords
- transmission
- channel
- segments
- data
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
- G06F11/2007—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1443—Transmit or communication errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
- G06F13/12—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
- G06F13/122—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware performs an I/O function other than control of data transfer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/85—Active fault masking without idle spares
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
- Debugging And Monitoring (AREA)
Abstract
Une interface de canaux multi-voies pour systèmes d'entrée/sortie d'ordinateur comprend la capacité de définir et d'activer des groupes non équilibrés de sous-canaux de transmission unidirectionnels pour une application utilisateur. Des identifications d'échange indépendantes du protocole permettent non seulement les groupes de transmission non équilibrés, mais autorisent également des extensions contrôlées par l'utilisateur afin de négocier les valeurs des paramètres de transmission à l'instant où le groupe de transmission est activé. Lorsque des réémissions de correction d'erreur forcent la resegmentation de blocs de données, une indexation de sous-segment de second niveau assure l'ordre de livraison approprié des différents segments et sous-segments. Les identifications d'échange comprennent une identification du protocole utilisateur qui est supporté et ainsi permettent l'interfaçage avec tout protocole utilisateur.
Description
INTERFACES DE CANAL AMELIOREES POUR DES CANAUX D'ENTREE/SORTIE
D'ORDINATEUR
Domaine technique
Cette. invention se rapporte aux mécanismes de transfert des données et plus particulièrement aux canaux d'entrée et sortie d'ordinateurs configurables dynamiquement, non équilibrés, transparents pour l'utilisateur, et à multi-canaux.
D'ORDINATEUR
Domaine technique
Cette. invention se rapporte aux mécanismes de transfert des données et plus particulièrement aux canaux d'entrée et sortie d'ordinateurs configurables dynamiquement, non équilibrés, transparents pour l'utilisateur, et à multi-canaux.
Arrière-plan de l'invention
Les systèmes d'ordinateurs centraux tels que 1IBMS/390 échangent des données entre des périphériques d'entrée/sortie et une mémoire principale par des opérations d'entrée/sortie connues sous le nom collectif de sous-système de canal. Les périphériques d'entrée/sortie et leurs unités de commande se rattachent au soussystème de canal. Le sous-système de canal constitue une combinaison de circuits et de logiciels qui commandent la circulation d'informations entre les unités de commande des périphériques d'entrée/sortie et la mémoire principale afin de soulager l'Unité
Centrale de l'ordinateur (UC) des taches de transmission avec les périphériques d'entrée/sortie. Le processus d'entrée / sortie peut de ce fait s'effectuer en même temps que le processus de données normal dans l'unité centrale. Le processus d'entrée/sortie comprend la gestion de voies, le test des voies pour leur disponibilité, le choix d'une voie de canal disponible et l'initialisation et la finalisation de l'exécution des opérations d'entrée/sortie au moyen des périphériques d'entrée/sortie. Une unité de contrôle est un mécanisme de conversion des caractéristiques d'un périphérique d'entrée/sortie particulier au format standard utilisé par le soussystème de canal.
Les systèmes d'ordinateurs centraux tels que 1IBMS/390 échangent des données entre des périphériques d'entrée/sortie et une mémoire principale par des opérations d'entrée/sortie connues sous le nom collectif de sous-système de canal. Les périphériques d'entrée/sortie et leurs unités de commande se rattachent au soussystème de canal. Le sous-système de canal constitue une combinaison de circuits et de logiciels qui commandent la circulation d'informations entre les unités de commande des périphériques d'entrée/sortie et la mémoire principale afin de soulager l'Unité
Centrale de l'ordinateur (UC) des taches de transmission avec les périphériques d'entrée/sortie. Le processus d'entrée / sortie peut de ce fait s'effectuer en même temps que le processus de données normal dans l'unité centrale. Le processus d'entrée/sortie comprend la gestion de voies, le test des voies pour leur disponibilité, le choix d'une voie de canal disponible et l'initialisation et la finalisation de l'exécution des opérations d'entrée/sortie au moyen des périphériques d'entrée/sortie. Une unité de contrôle est un mécanisme de conversion des caractéristiques d'un périphérique d'entrée/sortie particulier au format standard utilisé par le soussystème de canal.
Suivant les opérations d'entrée/sortie de la technique antérieure, un sous-canal est prévu pour chaque périphérique d'entrée/sortie accessible au sous-système de canal et lui est réservé. De tels sous-canaux constituent des voies de transmission plus logiques que physiques et sont définis en fonction d'exigence spécifique du périphérique d'entrée/sortie associé. Le nombre de tels sous-canaux n'est limité que par les tailles d'adresse que le système d'ordinateur peut reconnaitre. Ainsi, suivant les opérations d'entrée/sortie de la technique antérieure, les périphériques d'entrée/sortie sont liés au sous-système de canal au moyen de souscanaux logiques obtenus sur le support de transmission physique (appelé voie de canal) et activés lorsque les opérations d'entrée/sortie sont nécessaires. Les sous-canaux logiques sont définis comme étant des moyens de transmission pour des longueurs de paquet de données de tailles variées s'étendant de zéro à 32 kilooctets par pas de quatre kilooctets. Les unités de contrôle d'entrée/sortie sont reliées au sous-système de canal par un ou plus de ces sous-canaux logiques et un périphérique d'entrée/sortie peut étre desservi par une unité de contrôle ou plus. La plupart des périphériques d'entrée/sortie sont conçus pour ne transférer des données qu'à une vitesse spécifique et doivent être desservis par un sous-canal logique qui égale ou dépasse cette vitesse de périphérique. Bien que le support de transmission physique puisse fonctionner en mode duplex ou à l'alternatt les sous-canaux logiques ont été néanmoins définis pour des raisons de simplicité pour les deux sens de transmission afin de supporter à la fois les entrées et les sorties. La technique antérieure ne prévoyait pour les transmissions logiques des sous-canaux qui soient égaux, équilibrés et symétriques pour les deux sens de transmission. Les périphériques se voyaient affecter sous-canal unique à l'installation et les transmissions sur ce sous-canal se conformaient aux protocoles de transmission définis pour ce type de périphérique d'entrée/sortie.
On notera que tous les sous-canaux de la technique antérieure sont prédéfinis pour une destination d'entrée/sortie particulière, sont équilibrés, et sont simplement activés lorsque le système requiert une entrée/sortie. I1 existe une grande variété de programmations d'entrée et de sortie d'ordinateur qui utilisent les protocoles décrits ci-dessus.
Le nombre de sous-canaux logiques dans un tel système est indépendant du nombre de voies de canal, il peut être accédé au méme périphérique d'entrée/sortie par un certain nombre de voies de canaux différentes, représentées par un seul sous-canal logique. Le sous-canal logique conserve les adresses de la mémoire principale où les données doivent être lues ou écrites, un décompte des données transférées, l'identité de la destination et la mémorisation des informations d'état concernant le périphérique d'entrée/sortie relié. Ces informations d'état sont accessibles au moyen des processus programmés. Historiquement, les sous-canaux logiques étaient réalisés par des câbles multi-conducteurs, les bits étant transférés en parallèle sur différents conducteurs de cuivre (mode multiplex octets). De tels cables étaient limités en longueur (30 à 50 mètres) et en largeur de bande (1,5 à 4,5 Mb/s) et beaucoup de programmations d'entrée/sortie existantes sont adaptées à ces limitations. Ce type de support de transmission ancien est connu comme interface d'entrée/sortie parallèle et est davantage décrit dans "IBM System/360 and System/370 I/O Interface Channel to Control
Unit OEMI (Original Equipment Manufacturer Interface)", du document
IBM System Library GA22-6974, disponible chez IBM Corporation.
Unit OEMI (Original Equipment Manufacturer Interface)", du document
IBM System Library GA22-6974, disponible chez IBM Corporation.
Plus récemment, de nouveaux supports à fibres optiques sont devenus disponibles pour interconnecter des ordinateurs centraux avec des périphériques d'entrée/sortie. Ceci constitue une interface série d'entrée/sortie pour le sous-système de canal, comporte une largeur de bande d'au moins 20 Moctets/s et peut s'étendre sur de nombreux kilomètres (50 à 60 kilomètres) au moyen de répéteurs RCE (prolongateurs de canaux éloigné) . Un type de voies de canaux d'interface série est connu sous le nom de canal ESCON (connectivité de système d'entreprise) et est davantage décrit dans "IBM
Enterprise Systems Architecture/390 ESCON I/O Interface", du document IBM System Library SA22-7202, également disponible chez IBM
Corporation. L'interface d'entrée/sortie série ESCON utilise des salves de paquets de bits série (mode salve) et pose des problèmes au système de sous-canaux d'entrée/sortie standard à cause de sa largeur de bande de capacité plus élevée, du temps de retard inhérent aux distances plus importantes couvertes par le support, de l'intégrité du système (qui assure l'adaptation des affectations logiques aux deux extrémités du support), des problèmes de synchronisation apparaissant à cause de ces paramètres physiques variables.
Enterprise Systems Architecture/390 ESCON I/O Interface", du document IBM System Library SA22-7202, également disponible chez IBM
Corporation. L'interface d'entrée/sortie série ESCON utilise des salves de paquets de bits série (mode salve) et pose des problèmes au système de sous-canaux d'entrée/sortie standard à cause de sa largeur de bande de capacité plus élevée, du temps de retard inhérent aux distances plus importantes couvertes par le support, de l'intégrité du système (qui assure l'adaptation des affectations logiques aux deux extrémités du support), des problèmes de synchronisation apparaissant à cause de ces paramètres physiques variables.
Ainsi, un problème de base du sous-système de canaux est son manque de souplesse dans sa définition et dans l'activation des sous-canaux. Pour des applications modernes telles que Systems
Network Architecture (SNA) and Advanced Peer-to-Peer Networks (APPN), une plus grande souplesse est souhaitable pour s'adapter à la fois au multiplexage d'octets et aux voies de transmission en mode salve de telle manière qu'elles soient transparentes aux applications des utilisateurs existantes conçues lorsque seul le mode par multiplexage d'octets était disponible. En outre, la possibilité de couper de longs flux de données en segments pour leur transmission sur différents sous-canaux logiques qui peuvent être réalisés sur des voies de canaux différentes accroît le problème du séquencement, spécialement lors de pannes de la voie de canal. De plus, un certain degré de commande dynamique sur les paramètres des sous-canaux d'entrée/sortie est utile, et quelquefois nécessaire, pour des systèmes avancés tels que le SNA et 1'APPN. Les utilisateurs peuvent avoir besoin d'adapter des parties telles que, à titre d'exemple, la taille de mémoire tampon du récepteur ou la capacité de voies de transmission maximum disponible. Enfin, de nombreux périphériques et systèmes modernes ne nécessitent pas des canaux de transmission équilibrés présentant la même capacité dans les deux sens, du fait que beaucoup d'applications multimédia ne demandent que des activités de commande mineures pour commander des signaux multimédia à très large largeur de bande.
Network Architecture (SNA) and Advanced Peer-to-Peer Networks (APPN), une plus grande souplesse est souhaitable pour s'adapter à la fois au multiplexage d'octets et aux voies de transmission en mode salve de telle manière qu'elles soient transparentes aux applications des utilisateurs existantes conçues lorsque seul le mode par multiplexage d'octets était disponible. En outre, la possibilité de couper de longs flux de données en segments pour leur transmission sur différents sous-canaux logiques qui peuvent être réalisés sur des voies de canaux différentes accroît le problème du séquencement, spécialement lors de pannes de la voie de canal. De plus, un certain degré de commande dynamique sur les paramètres des sous-canaux d'entrée/sortie est utile, et quelquefois nécessaire, pour des systèmes avancés tels que le SNA et 1'APPN. Les utilisateurs peuvent avoir besoin d'adapter des parties telles que, à titre d'exemple, la taille de mémoire tampon du récepteur ou la capacité de voies de transmission maximum disponible. Enfin, de nombreux périphériques et systèmes modernes ne nécessitent pas des canaux de transmission équilibrés présentant la même capacité dans les deux sens, du fait que beaucoup d'applications multimédia ne demandent que des activités de commande mineures pour commander des signaux multimédia à très large largeur de bande.
Plus particulièrement, il était courant dans le passé de prévoir des périphériques d'entrée/sortie composés de simples périphériques tels que les imprimantes, les unités de bande magnétique, les unités de disque magnétique, les terminaux et les sous-canaux d'autres systèmes de processus de données. Aujourd'hui cependant, de tels ordinateurs communiquent avec des périphériques si tués à de grandes distances géographiques reliées par de longs systèmes de transmission qui peuvent comprendre des réseaux locaux ou sur une zone étendue. De tels systèmes interconnectés présentent d'autres exigences que des périphériques d'entrée/sortie plus simples. En particulier, comme on l'a remarqué ci-dessus, des services tels que le multimédia réparti nécessitent des possibilités de transmission largement non équilibrées dans les deux sens de transmission. En outre, il n'est pas toujours possible d'avoir une connaissance prédéterminée des services disponibles à l'autre extrémité d'un long canal d'entrée/sortie, et il n'existe pas de possibilité prévue dans les superviseurs d'entrée/sortie de la technique antérieure pour communiquer les paramètres nécessaires entre les deux extrémités du sous-canal. Une certaine forme de sécurité de système est également souhaitable pour s'assurer que les deux extrémités des sous-canaux possèdent les autorisations appropriées pour les interconnexions.
Enfin, la possibilité de partager de grands blocs de données en segments pour la retransmission dans le cas de pannes de voies de canaux fait apparaitre la possibilité de problèmes de séquencement de segment et de sous-segment qui n1 existe pas dans les systèmes à sous-canaux unique simple.
Les configurations d'ordinateur à attachement canal présentent aujourd'hui un environnement radicalement différent de l'environnement de canaux traditionnel. Auparavant, il était possible de supposer une proximité géographique qui entrainait un certain degré de controle local sur des aspects importants de la conception du système de canal. Aujourd'hui, l'environnement de canal, plus fluctuant et diversifié, donne lieu à un certain nombre de problèmes de conception de système. Par exemple, la sécurité de canaux était facile à assurer lorsque les distances étaient limitées à des unités exprimées en termes de mètres et il y avait peu de chance de pénétration du système par un système pirate. Au contraire, les distances d'un canal sont mesurées aujourd'hui en unités de kilomètres. La technologie du prolongateur de canal étend cette distance sur une connectivité mondiale. En outre, les systèmes antérieurs fournissaient un certain degré de sécurité par l'utilisation de définitions statiques prédéfinies. La souplesse des définitions dynamiques fait également apparaitre une vulnérabilité accrue à la pénétration par un système pirate.
Un autre problème posé par les systèmes de canaux de la technique antérieure est la connaissance locale implicite de la capacité de mémoire tampon d'un partenaire de sous-canal. Dans de tels systèmes de la technique antérieure, toute implémentation spécifique à un partenaire de sous-canaux faisait des hypothèses sur la capacité du partenaire. En cas d'erreur, ces hypothèses conduisent à une inefficacité significative du système. De la même manière, les sens de transmission prédéfinis de façon statique, soit à l'alternat, soit unidirectionnelle, sont souvent inadaptés à des transferts de données particuliers. Les sens de transmission définis de façon dynamique et modifiable conviendraient mieux aux exigences de transfert de données plus souples d'aujourd'hui. Enfin, les applications des utilisateurs sont normalement conçues en ayant à l'esprit un périphérique particulier ou un type de périphérique, et des protocoles de niveau d'utilisateur plus élevé sont adaptés à ce périphérique particulier ou ce type de périphérique. Ceci nécessite la réalisation d'une interface pour chaque apllication d'utilisateur afin d'adapter les protocoles utilisateurs au sous-système de canal.
Une méthodologie unique pourrait remplacer ces interfaces existantes en fournissant un ensemble unique d'interfaces de système.
Les interfaces de canal de la technique antérieure ne fournissent que des interfaces à allocation de largeur de bande équilibrées. De telles interfaces à allocation équilibrée nécessitent que la largeur de bande d'émission, ou d'écriture, soit égale à celle de la réception, ou de lecture. Alors que cette approche convient et est en fait souhaitable, dans les transactions de la technique antérieure ou dans les environnements de traitement par lot à faible rendement à cause du flux de données pratiquement équilibré, les environnements client/serveur d'aujourd'hui, par nature même, imposent des interfaces à largeur de bande grandement déséquilibrées. De la même manière, les nouveaux services de mode de transfert asynchrone (ATM) sur les réseaux longueur distance (WAN) fournissent de la même manière des interfaces de réseau non équilibrées.
Résumé de l'invention
Conformément au mode de réalisation illustrant la présente invention, une interface à canaux multi-voies (MPC) est décrite, laquelle réalise une interface transparente entre les applications utilisateur employant un canal d'entrée/sortie de la technique antérieure et les processus de superviseur d'entrée/sortie de voies de canaux de la technique antérieure à la fois pour le multiplexage d'octets et les voies de transmission en mode salve. Plus particulièrement, il est décrit une nouvelle interface d'entrée/sortie qui permet à l'application de l'utilisateur de définir des groupes de canaux multi-voies (MPC) pour son utilisation propre qui peut inclure des possibilités de transmission non équilibrée entre l'ordinateur hôte et le service distant. En outre, les données de l'utilisateur sont mises sous forme de blocs pour utiliser les sous-canaux de transmission disponibles et retransmis sur les mêmes sous-canaux ou des sous-canaux différents lorsque des erreurs de données sont détectées. Des mécanismes de reséquencement sont prévus pour assurer une reconstitution appropriée du flux de données lors de retards différents lors de l'émission initiale et des ré-émissions de correction d'erreur des paquets de données. De telles ré-émissions sont particulièrement gênantes lorsqu'il est nécessaire de resegmenter des blocs de données pour s'adapter à la capacité inférieure de sous-canaux disponibles pour de telles réémissions. Conformément à la présente invention, une telle intégrité de séquence est conservée en sous-indexant les blocs de données qui sont resegmentés pour les ré-émissions de correction d'erreur.
Conformément au mode de réalisation illustrant la présente invention, une interface à canaux multi-voies (MPC) est décrite, laquelle réalise une interface transparente entre les applications utilisateur employant un canal d'entrée/sortie de la technique antérieure et les processus de superviseur d'entrée/sortie de voies de canaux de la technique antérieure à la fois pour le multiplexage d'octets et les voies de transmission en mode salve. Plus particulièrement, il est décrit une nouvelle interface d'entrée/sortie qui permet à l'application de l'utilisateur de définir des groupes de canaux multi-voies (MPC) pour son utilisation propre qui peut inclure des possibilités de transmission non équilibrée entre l'ordinateur hôte et le service distant. En outre, les données de l'utilisateur sont mises sous forme de blocs pour utiliser les sous-canaux de transmission disponibles et retransmis sur les mêmes sous-canaux ou des sous-canaux différents lorsque des erreurs de données sont détectées. Des mécanismes de reséquencement sont prévus pour assurer une reconstitution appropriée du flux de données lors de retards différents lors de l'émission initiale et des ré-émissions de correction d'erreur des paquets de données. De telles ré-émissions sont particulièrement gênantes lorsqu'il est nécessaire de resegmenter des blocs de données pour s'adapter à la capacité inférieure de sous-canaux disponibles pour de telles réémissions. Conformément à la présente invention, une telle intégrité de séquence est conservée en sous-indexant les blocs de données qui sont resegmentés pour les ré-émissions de correction d'erreur.
Toujours conformément à la présente invention, les messages d'identification d'échanges normaux entre les extrémités des souscanaux d'entrée/sortie sont adaptés aux utilisateurs de manière à acheminer dynamiquement les informations vers l'autre extrémité d'un sous-canal d'entrée/sortie en fonction des périphériques disponibles pour manipuler les signaux d'entrée/sortie, comme la taille de la mémoire tampon ou les limitations de voies de données.
Toujours en conformité avec le mode de réalisation illustrant la présente invention, lorsque des segments de données doivent etre réémis à la suite d'une panne de voies de canal, un périphérique de sous-indexation de segment est utilisé afin d'étiqueter les soussegments d'un bloc de transmission qui a été émis auparavant mais non reçu. Du fait qu'une telle ré-émission doit être faite sur les sous-canaux du groupe de transmission qui reste opérationnel, il peut se produire que les sous-canaux disponibles présentent individuellement une capacité insuffisante pour transmettre le segment ré-émis. I1 devient alors nécessaire de resegmenter le segment ré-émis pour s'adapter aux sous-canaux disponibles. Une telle resegmentation, à son tour, amène la possibilité d'une réception des sous-segments dans le désordre. L'indexation des soussegments comprend l'étiquetage nécessaire pour réassembler de façon appropriée le bloc de transmission d'origine à partir des segments et des sous-segments, indépendamment de l'ordre de leur réception.
Une file d'attente en réception de données est bien entendu incluse, afin de réassembler les données de l'utilisateur dans l'ordre suivant lequel elles ont été émises avant leur présentation à l'interface de canaux multi-voies.
Brève description des dessins
La figure 1 représente un schéma synoptique général d'un système d'entrée/sortie d'ordinateur dans lequel interface de canaux multi-voies de la présente invention peut être utilisée.
La figure 1 représente un schéma synoptique général d'un système d'entrée/sortie d'ordinateur dans lequel interface de canaux multi-voies de la présente invention peut être utilisée.
La figure 2 présente une représentation graphique de la structure des blocs de transmission utilisés pour les transmissions des données d'entrée et des signaux de commande du système de la figure 1 conformément à la présente invention.
La figure 3 présente un schéma synoptique plus détaillé de l'interface de canaux multi-voies représenté sur la figure 1, montrant l'architecture de l'interface.
La figure 4 représente un exemple caractéristique de configurations de canaux multi-voies qui sont crées et qui peuvent être exploitées par l'interface de canaux multi-voies de la présente invention.
La figure 5 représente le format d'un signal de commande d'identification d'échange (XID) caractéristique qui pourrait être utilisé dans le système d'interface de canaux multi-voies de la présente invention pour les transmissions avec un contrôleur tel qu'un VTAM dans un réseau par paquet SNA.
La figure 6 représente une extension optionnelle du format de signal de commande XID présenté sur la figure 5 afin d'indiquer la taille de mémoire tampon de lecture disponible maximale à l'extrémité en réception pour un transfert d'entrée/sortie.
La figure 7 représente un organigramme détaillé du processus d'activation du sous-canal utilisé par l'interface de canaux multivoies de la figure 3 conformément à la présente invention.
La figure 8 représente un organigramme plus détaillé de l'échange de signaux d'identification d'échange (XID) utilisé dans le processus d'activation de la figure 9, et
La figure 9 représente un organigramme détaillé du processus de sous-indexation de segment de l'interface de canaux multi-voies de la figure 3, en conformité avec la présente invention, qui est utilisé lorsque la ré-émission de segments de données doit être faite sur des sous-canaux présentant une capacité intérieure à la capacité du canal sur lequel l'émission d'origine du segment prend place.
La figure 9 représente un organigramme détaillé du processus de sous-indexation de segment de l'interface de canaux multi-voies de la figure 3, en conformité avec la présente invention, qui est utilisé lorsque la ré-émission de segments de données doit être faite sur des sous-canaux présentant une capacité intérieure à la capacité du canal sur lequel l'émission d'origine du segment prend place.
Afin de faciliter la compréhension du lecteur, des références numériques identiques sont utilisées pour désigner les éléments communs aux figures.
Description détaillée
En se référant plus particulièrement à la figure 1, il est présenté un schéma synoptique général d'un système d'entrée/sortie d'ordinateur pour un ordinateur central relié à un canal 21 et comprenant une application utilisateur 10 qui s'exécute sur l'ordinateur 21 et qui nécessite des capacités de fonctions d'entrée/sortie (E/S). L'ordinateur 21 comprend également une interface de canaux multi-voies 12 qui commande l'entrée et la sortie des données entre l'ordinateur 21 et un périphérique ou système distant 17 sur une voie de canal ou plus 22, 23, ou 24. Les voies de canaux 22 à 24 utilisent des adaptateurs 14, 15, 16, 18, 19, et 20 pour convertir les signaux de données pour leur émission sur les supports 22 à 24. L'interface de canaux multi-voies 12 commande la liaison des signaux de données d'utilisateur entre l'application utilisateur 10 et le support 22 à 24 en mettant en forme les données dans des unités de données de protocole (PDU) convenant aux voies de canaux 22 à 24. Les périphériques ou systèmes 17 peuvent inclure des périphériques d'entrée/sortie simples tels que des imprimantes, des systèmes de mémoires ou des terminaux, ou peuvent inclure d'autres ordinateurs centraux avec lesquels l'application utilisateur 10 souhaite communiquer. Le système 17 peut également comprendre un accès à un réseau à données réparties longue distance ou local comportant des ordinateurs ou des périphériques d'entrée/sortie situés à distance et qui lui sont rattachés.
En se référant plus particulièrement à la figure 1, il est présenté un schéma synoptique général d'un système d'entrée/sortie d'ordinateur pour un ordinateur central relié à un canal 21 et comprenant une application utilisateur 10 qui s'exécute sur l'ordinateur 21 et qui nécessite des capacités de fonctions d'entrée/sortie (E/S). L'ordinateur 21 comprend également une interface de canaux multi-voies 12 qui commande l'entrée et la sortie des données entre l'ordinateur 21 et un périphérique ou système distant 17 sur une voie de canal ou plus 22, 23, ou 24. Les voies de canaux 22 à 24 utilisent des adaptateurs 14, 15, 16, 18, 19, et 20 pour convertir les signaux de données pour leur émission sur les supports 22 à 24. L'interface de canaux multi-voies 12 commande la liaison des signaux de données d'utilisateur entre l'application utilisateur 10 et le support 22 à 24 en mettant en forme les données dans des unités de données de protocole (PDU) convenant aux voies de canaux 22 à 24. Les périphériques ou systèmes 17 peuvent inclure des périphériques d'entrée/sortie simples tels que des imprimantes, des systèmes de mémoires ou des terminaux, ou peuvent inclure d'autres ordinateurs centraux avec lesquels l'application utilisateur 10 souhaite communiquer. Le système 17 peut également comprendre un accès à un réseau à données réparties longue distance ou local comportant des ordinateurs ou des périphériques d'entrée/sortie situés à distance et qui lui sont rattachés.
Plus particulièrement, les voies de canaux 22, 23 . , 24 peuvent comprendre des cables à multi-conducteurs de multiplexage d'octets standard, des fibres optiques en mode salve ou toute autre forme de support de transmission sur lequel des blocs de données peuvent etre transmis. Le nombre de telles voies de canaux peut varier sur toute la gamme allant d'une voie bidirectionnelle ou à l'alternat unique jusqu'à autant que nécessaire ou souhaité pour transporter les données qui doivent être transmises à partir de l'ordinateur 21. Dans un but de simplicité, chacune des voies de canaux 22 à 24 est supposée être utilisée en mode à l'alternat , et émettant dans un seul sens à la fois. Bien que le sens de transmission puisse être inversé, les temps de retard élevés possibles imposent que de telles inversions soient minimisées. Les modifications nécessaires pour profiter des avantages du fonctionnement en duplex des voies 22 à 24 sont considérées comme étant évidentes et ne seront pas davantage décrites ici.
Conformément à la présente invention, une interface de canaux multi-voies 12 est reliée entre une application utilisateur 10 et des voies de canaux 22 à 24 pour procurer une interconnexion transparente entre l'application utilisateur 10 de la technique antérieure et les voies de canaux 22 à 24 de la technique antérieure qui permettent le même niveau de fonctionnalité dans les environnements de transfert de données modernes que celui qui était disponible dans les systèmes de la technique antérieure plus simples et plus localisés. Plus particulièrement, un nouvel ensemble de message d'identification d'échange (XID) a été défini (qui sera présenté en liaison avec les figures 5 à 8) et qui procure à l'utilisateur un ensemble de fonctions qui satisfont les exigences d'interface de système de base, et, en outre, procurent un ensemble de zones de données définies par l'utilisateur, optionnelles, qui peuvent etre utilisées pour réaliser les exigences spécifiques à l'application, dont certaines seront décrites ci-dessous, mais qui peuvent comprendre l'établissement de paramètres du système et la réservation de champs de vérification (sécurité) du système fourni par l'utilisateur (par exemple, les mots de passe cryptés).
L'échange de paramètres du système tels que la taille et la commande de la mémoire tampon, le sens du flux de données et le support de protocole utilisateur à un niveau plus élevé permet des échanges de données d'entrée/sortie efficaces et rapides.
Avant de procéder à une description détaillée de l'interface de canaux multi-voies 12 de la figure 1, on décrira le format des données et des signaux de commande transmis sur les voies de transmission 22 à 24 conformément à la technique antérieure. Il est montré sur la figure 2 une représentation graphique d'un bloc de transmission caractéristique sur les voies de transmission 22 à 24 comprenant un en-tete de bloc de transmission 25 suivi d'une unité de données de protocole ou plus (PDU) 27, 29, chacune comportant son propre en-tête 26 et 28, respectivement. Ainsi, le PDU1 27 comporte un en-tête de PDU 26 et le PDU2 29 comporte un en-tete de PDU 28.
Quelques uns des détails des en-tetes 25, 26, et 27 sont également présentés sur la figure 2 dans le pavé figurant sous len-tete 25 et relié par des lignes en tirets à l'en-tète 25. Ainsi, l'en-tête de bloc de transmission 25 est représenté comme comprenant un champ de numéro de segment 30 utilisé pour contenir un nombre représentant la séquence de ce bloc en une pluralité de blocs de données transmises par la même application utilisateur 10 à la même destination. Une pluralité de champs de contrôle 31 sont également inclus dans len-tete de bloc de transmission 25 et contiennent les informations nécessaires pour les diverses actions de commande à l'extrémité distante, en particulier lorsque le bloc de transmission est destiné à être transmis sur un système de réseau par paquets à l'extrémité distante. Un indicateur, également inclus dans les champs de contrôle 31, marque le dernier segment d'un bloc de données utilisateur segmenté. Le champ 32 contient un numéro de séquence concernant ce bloc lorsque le segment d'origine (tel que le bloc de transmission complet de la figure 2) est remis sous forme de bloc en blocs plus petits lorsque cela est nécessité pour une réémission consécutive à un échec de réception du bloc d'origine. Ce numéro de séquence est utilisé, comme cela sera décrit plus loin, pour reconstituer la séquence appropriée des segments remis sous forme de bloc après leur réception à l'extrémité distante de la voie de canal.
Chacun des PDU 27, 29 ..., comporte un en-tete de PDU comprenant un champ de longueur de PDU 33 et un champ d'indicateurs de PDU 34.
On notera que les PDU peuvent contenir soit des données utilisateur, soit des informations de commande MPC. L'un des indicateurs du champ 34 indique si les informations qui suivent sont des données utilisateur ou des signaux de commande MPC. Un type de tel signal de commande MPC est représenté par les signaux d'identification d'échange (XID) qui seront présentés en liaison avec les figures 5 à 8. Des indicateurs sont également disponibles dans le champ 34 afin d'indiquer le type d'unité de données, si cela est approprié, et d'identifier le dernier PDU dans un bloc de transmission. Le champ d'identification de protocole 35 est utilisé pour identifier le protocole utilisé par l'application utilisateur qui est à la source de ce PDU de données. Cette identification de protocole permet au système distant de traiter les données utilisateur avec le processus de protocole approprié et de rendre le processus de commande de sous-canal indépendant du protocole de l'application utilisateur 10 de la figure 1 L'en-tète de PDU 26 comprend également un champ de numéro de séquence 36 afin d'établir la séquence initiale d'une pluralité de PDU mis en bloc ensemble, au cas où de tels numéros de séquence s'avéreraient nécessaires pour reconstituer un bloc de transmission désassemblé. Comme cela sera décrit en liaison avec les figures 8 à 12, les PDU de contrôle peuvent comprendre des champs optionnels qui peuvent être utilisés par l'application utilisateur afin d'adapter les valeurs des variables à utiliser dans la mise sous forme de bloc et dans la mise en file d'attente des données utilisateur
Sur la figure 3 est représenté un schéma synoptique plus détaillé de l'interface de canaux multi-voies 12 de la figure 1, qui comprend trois composantes majeures. Le gestionnaire de données MPC 45 réalise l'interface avec l'application utilisateur 10 de la figure 1 et comprend un processus de formatage de données en sortie 46 qui convertit les données et le flux de commande de l'application utilisateur 10 en blocs adaptés à l'émission sur les voies de canaux disponibles 22 à 24. Le gestionnaire de données 45 comprend également des files d'attente de données en entrée qui acceptent les données provenant de l'extrémité éloignée des voies de transmission 22 à 24 et les mémorisent pour les délivrer à l'application utilisateur 10. Un sous-système de commande de transmission sur un interface de canaux multi-voies 48 réalise l'interface entre les signaux de commmande et de données provenant du gestionnaire de données 46 et une pluralité de sous-canaux d'entrée et sortie logiques 49 à 54 sur lesquels les transmissions d'entrée et sortie peuvent être faites. On notera que les sorties des processus 48 sont des sous-canaux logiques qui sont unidirectionnels et adaptés à la transmission de blocs de transmission de taille fixe variant de zéro à 64 kilooctets de longueur. Le superviseur de transmission de la technique antérieure 13 (figure 1) convertit ces sous-canaux logiques en capacité de transmission physique multiplexée sur les voies de canaux physiques 22 à 24, en restant totalement conforme aux processus connus de la technique antérieure. On notera cependant que les sous-canaux logiques 49 à 54 représentés sur la figure 3 ne nécessitent pas d'être équilibrés et que plus ou moins de canaux d'entrée peuvent être combinés avec un nombre différent de canaux de sortie.
Sur la figure 3 est représenté un schéma synoptique plus détaillé de l'interface de canaux multi-voies 12 de la figure 1, qui comprend trois composantes majeures. Le gestionnaire de données MPC 45 réalise l'interface avec l'application utilisateur 10 de la figure 1 et comprend un processus de formatage de données en sortie 46 qui convertit les données et le flux de commande de l'application utilisateur 10 en blocs adaptés à l'émission sur les voies de canaux disponibles 22 à 24. Le gestionnaire de données 45 comprend également des files d'attente de données en entrée qui acceptent les données provenant de l'extrémité éloignée des voies de transmission 22 à 24 et les mémorisent pour les délivrer à l'application utilisateur 10. Un sous-système de commande de transmission sur un interface de canaux multi-voies 48 réalise l'interface entre les signaux de commmande et de données provenant du gestionnaire de données 46 et une pluralité de sous-canaux d'entrée et sortie logiques 49 à 54 sur lesquels les transmissions d'entrée et sortie peuvent être faites. On notera que les sorties des processus 48 sont des sous-canaux logiques qui sont unidirectionnels et adaptés à la transmission de blocs de transmission de taille fixe variant de zéro à 64 kilooctets de longueur. Le superviseur de transmission de la technique antérieure 13 (figure 1) convertit ces sous-canaux logiques en capacité de transmission physique multiplexée sur les voies de canaux physiques 22 à 24, en restant totalement conforme aux processus connus de la technique antérieure. On notera cependant que les sous-canaux logiques 49 à 54 représentés sur la figure 3 ne nécessitent pas d'être équilibrés et que plus ou moins de canaux d'entrée peuvent être combinés avec un nombre différent de canaux de sortie.
Le gestionnaire de données de contrôle 45 et les processus de contrôle de transmission 48 constituent un ensemble de processus de contrôle MPC 40. Un processus d'allocation et de désallocation de périphérique ou de système 41 est compris dans le processus 40 et utilise les signaux de contrôle provenant de l'application utilisateur 10 afin d'allouer des canaux multi-voies équilibrés ou non équilibrés à une application utilisateur. Comme on l'a noté cidessus, ces allocations de canaux multi-voies vérifient simplement que les possibilit d'erreur provenant du périphérique ou système distant indiquant les segments de données manquants ou dégradés au périphérique ou système distant. Le processus de réémission de données 44 répond au processus de contrôle d'erreur 43 afin de réémettre les blocs de données manquants ou dégradés, comme cela sera décrit plus en détail en liaison avec la figure 11.
Alors que les processus de la figure 3 pourraient être réalisés au moyen d'éléments de circuit spécialisés d'une façon qui est évidente pour l'homme de l'art, ces processus sont de préférence réalisés au moyen de processus programmés sur un ordinateur central d'usage général 21. Ces processus seront décrits en détail en liaison avec les organigrammes des figures 9 à 11. Il est considéré que les programmations réelles de ces processus sont largement comprises dans les capacités de toute personne ayant des connaissances ordinaires dans la technique de programmation des transmissions en partant de ces organigrammes et des descriptions suivantes.
Sur la figure 4 est montrée une représentation graphique d'un canal multi-voies équilibré caractéristique et d'un canal multivoies non équilibré caractéristique alloués par l'interface de canaux multi-voies de la figure 3 en réponse à des demandes (d'allocation d'un canal multi-voies) de l'application utilisateur 10 de la figure 1. Des applications utilisateur communiquent avec le MPC 12 au moyen de messages réalisant des fonctionnalités telles que l'allocation ou l'affectation de sous-canaux à une application utilisateur particulière. De telles allocations sont simplement des réservations logiques qui ne sont pas activées avant qu'un signal
CCW (canal activé) soit procuré. Le message de canal alloué permet à l'utilisateur de spécifier les groupes de transmission comportant toute combinaison de sous-canaux de toute taille et de sens de transmission quelconque. Il est de ce fait possible à une application utilisateur de spécifier des groupes de canaux multivoies non-équilibrés dans lesquels les tailles des sous-canaux lus sont différentes des tailles des sous-canaux écrits afin de s'adapter aux applications non équilibrées telles que la répartition multimédia. Un tel groupe de transmission non équilibré est représenté sur la figure 4.
CCW (canal activé) soit procuré. Le message de canal alloué permet à l'utilisateur de spécifier les groupes de transmission comportant toute combinaison de sous-canaux de toute taille et de sens de transmission quelconque. Il est de ce fait possible à une application utilisateur de spécifier des groupes de canaux multivoies non-équilibrés dans lesquels les tailles des sous-canaux lus sont différentes des tailles des sous-canaux écrits afin de s'adapter aux applications non équilibrées telles que la répartition multimédia. Un tel groupe de transmission non équilibré est représenté sur la figure 4.
A titre de comparaison, un groupe TG1 de groupe de canaux équilibré de la technique antérieure 62 est représenté sur la figure 4, comprenant un sous-canal d'écriture 63 et un sous-canal de lecture 64, les deux étant desservis par une voie de canaux 70. La voie de canal 70 peut bien sûr comprendre un support de transmission par cable multi-conducteur en mode octet multiplexé OEMI, un câble à fibre optique en mode salve ESCON, ou tout autre support de transmission. On suppose sur la figure 4 que l'application utilisateur locale 60 communique avec une application utilisateur distante 81 à l'autre extrémité des voies de transmission 70 et 71.
On suppose également qu'une interface de canaux multi-voies éloignée 72 dessert l'utilisateur éloigné 81 de la même manière que le MPC local 61 dessert l'utilisateur local 60. La figure 4 est de ce fait complètement symétrique.
Ainsi, les sous-canaux d'écriture 63, 66, 67, et 68 du MPC local 61 sont des canaux de lecture 73, 75, 76, et 77, respectivement, dans le MPC distant 72 et les sous-canaux de lecture 64 et 69 dans le MPC local 61 sont des canaux d'écriture 74 et 78, respectivement, dans le MPC distant 72. C'est-à-dire que chaque sous-canal logique est unidirectionnel. De plus, les groupes de canaux multi-voies 62 et 65 du MPC local 61 correspondent précisément aux groupes de canaux multi-voies 79 et 80, respectivement, du MPC distant 72.
L'allocation et l'activation des sous-canaux de la figure 4 est initialisée à la fois par l'application utilisateur locale 60 et l'application utilisateur distante 81 et, en fait, peut être initialisée simultanément à la fois par les applications utilisateur 60 et 81. Une technique de résolution des ambiguités qui peuvent se présenter lorsque les deux extrémités du groupe de transmission essaient d'allouer ou d'activer simultanément le groupe de transmission entre celles-ci est décrit en liaison avec la figure 10. La technique pour conserver le séquencement approprié des blocs de données dans le cas d'une remise sous forme de blocs multiples des données afin de faire face à des pannes de voies de canaux est décrite en liaison avec la figure 11.
Une application utilisateur telle que l'application utilisateur 60 de la figure 4 communique avec l'interface de canaux multi-voies telle que l'interface 61 sur la figure au moyen de messages donnant les instructions au MPC afin d'allouer, d'activer, et de désactiver les groupes de canaux multi-voies, et d'initialiser l'envoi des données et d'achever l'envoi des données. En réponse à ces signaux, le MPC 61 (ou le MPC 72) crée les groupes de canaux multi-voies logiques, active ces groupes pour la transmission réelle des données et notifie à l'utilisateur de commencer à envoyer les données ou de commencer à recevoir les données. Lorsque le groupe de canaux multivoies n'est plus nécessaire, le groupe est désactivé et lorsque le groupe de canaux multi-voies n'est plus valide, le groupe est désalloué. La transmission entre les MPC 61 et 72 se fait au moyen de signaux d'identification d'échange (XID) qui acheminent les informations nécessaires vers le partenaire distant afin de valider et d'invalider des voies de transmission. En particulier, un bloc de signal de commande XID ou plus est lancé sur chacun des souscanaux d'un groupe de canaux multi-voies afin d'effectuer l'activation de ce sous-canal. Ce n'est qu'après que tous les souscanaux d'un groupe sont activés avec succès aux deux extrémités que l'utilisateur reçoit le signal de commencer la transmission des données. Conformément à la présente invention, ces signaux d'activation de sous-canaux comprennent le moyen d'activer les groupes de transmission déséquilibrés et de notifier au partenaire distant les tailles de la mémoire tampon et des voies pour les données actuellement disponibles, ce qui permet des modifications dynamiques dans les affections du groupe de transmission pour profiter des avantages ou pour se conformer aux possibilités actuellement disponibles. Sur les figures 5 et 6 sont représentés un message caractéristique XID utilisé par les MPC 61 et 72 de la figure 4 afin d'obtenir ces résultats. D'autres formats XID concernant d'autres buts seront évidents aux personnes de connaissance normale dans la technique à partir de la description suivante. En fait, l'un des avantages majeurs de la présente invention est la possibilité que les utilisateurs adaptent les formats XID pour obtenir des buts spécifiques des utilisateurs et cependant conformes aux exigences globales de l'interface MPC 12 de la figure 1.
Ainsi, sur la figure 5 est montrée une représentation graphique du format d'un message XID destinée à activer un sous-canal particulier d'un groupe de canaux multi-voies tel que ceux représentés sur la figure 4. Le message XID de la figure 5 comporte un champ d'en-téte 90 qui identifie le type de station locale, l'adresse de la destination et la longueur du message XID. Le champ 91 porte une identification du groupe de canaux multi-voies à activer, alors que le champ 92 contient l'état du groupe de canaux multi-voies (actif ou inactif). Le champ 93 contient l'identification d'un protocole utilisateur particulier, par exemple le protocole SNA. Le champ 93 pourrait bien sûr contenir l'identité d'un protocole utilisateur différent (par exemple, DECNet ou TCP/IP) auquel cas des informations différentes pourraient être incluses et un processus différent des messages XID pourrait être appelé. Le champ d'identification de protocole 93 permet à la meme structure de signal XID d'être utilisé avec différents protocoles et rend ainsi l'interface de canaux multi-voies de la présente invention totalement indépendante du protocole utilisateur.
Le champ 94 du message XID de la figure 5 contient l'état XID (OK ou NG) à utiliser comme cela sera présenté en liaison avec la figure 10, et aide à correler les opérations aux deux extrémités du groupe de transmission. Le champ d'adresse de source 95 identifie l'expéditeur pour l'interface MPC de réception distante, alors que le champ d'option XID 96 identifie ce message comme étant un signal d'activation de canal de groupe de canaux multi-voies. Le champ 97 identifie ce canal comme étant un canal de lecture ou d'écriture du point de vue des expéditeurs et procure la base de création de groupes de transmission non équilibrés. C'est-à-dire que, du fait qu'un signal XID similaire à celui de la figure 5 est transmis sur chacun des sous-canaux du groupe de transmission, le MPC expéditeur a la capacité de spécifier des groupes non équilibrés uniquement en spécifiant les options de lecture et d'écriture non équilibrées dans le champ 97.
Le message d'activation XID de la figure 5 peut être en option étendu au moyen des champs d'extension représentés sur la figure 6 à chaque fois qu'une application particulière nécessite une telle extension. Dans le cas illustré sur la figure 6, il est supposé que la station expéditrice ne connaît nécessairement pas la taille des mémoires tampons du récepteur. Il est de ce fait nécessaire pour les deux stations de spécifier la taille de mémoire tampon maximum disponible pour la réception des blocs de données dans le champ 98 de la figure 6. De manière similaire, le champ 97 est utilisé pour notifier à la station distante que des services sont disponibles localement pour manipuler des unités de données du protocole contigu (PDU) . La taille de mémoire tampon et la capacité de manipuler de façon contigue sont des paramètres importants dans la détermination de la taille et de la fréquence des transmissions de données sur le groupe de canaux et sont utilisés par l'interface de canaux multivoies de la figure 3, et en particulier par les processus de contrôle de transmission 48 de la figure 3 pour bloquer et émettre de façon appropriée les données utilisateurs.
On peut voir que les messages XID des figures 5 et 6 permettent des groupes de transmission non équilibrés et la configuration dynamique de certains paramètres de transmission au moment où un groupe de transmission est activé, le tout en conformité avec la présente invention. En outre, la possibilité de formater différents messages XID en fonction de protocoles utilisateurs différents, rend le fonctionnement total de l'interface de canaux multi-voies de la présente invention indépendant du protocole de l'application utilisateur. Cette indépendance vis à vis du protocole permet à une très large variété d'utilisateurs de profiter des avantages de la même interface MPC. Avant de passer à une description détaillée de l'organigramme de l'échange XID en conformité avec la présente invention, le processus global sera décrit.
Le processus consistant à allouer et activer un groupe de canaux multi-voies est initialisé en réponse à une demande de l'application utilisateur 10 de la figure 1. Ce processus effectué dans l'interface MPC locale, essaie initialement d'allouer les possibilités de transmission locale suivant un groupe de transmission logique qui satisfait la demande. Chacun des souscanaux locaux est validé pour disponibilité. Les voies de transmission physiques sont alors établies afin de permettre l'émission d'un message (XID-1) d'identification d'échange de première phase entre les interfaces MPC locales et distantes. Le message XID-1 présente le format décrit en liaison avec les figures 5 à 6, et transporte les informations obligatoires et en option concernant les voies de transmission demandées. Ce message XID-1 est dupliqué et émis sur chacun des sous-canaux du groupe de canaux multi-voies demandé. Pendant ce temps, à l'extrémité distante du support de transmission, une application utilisateur similaire sera la requête d'un groupe de canaux multi-voies similaire de l'interface MPC distante, mais en se conformant aux exigences spécifiques de l'application utilisateur distante. Du fait que ces exigences peuvent être différentes des exigences de l'application utilisateur locale, un certain mécanisme pour établir le paramètre à utiliser est requis. Une seconde phase d'échange XID (XID-2) sera utilisée pour résoudre ces différences. On notera, cependant, que les protocoles de la technique antérieure n'ont pas besoin de connaitre les échanges XID multiples et qu'il leur sera simplement notifié d'initialiser la transmission des données lorsque les échanges multiples sont achevés avec succès.
A l'interface MPC distante, les messages XID-1 reçus sur chacun des sous-canaux du groupe de transmission sont comparés l'un à l'autre afin de déterminer s'ils sont identiques. L'interface MPC distante vérifie, également, que les messages XID-1 ont été reçus sur chacun des sous-canaux du groupe de transmission. L'interface
MPC distante valide également la taille et le sens des sous-canaux demandés afin de déterminer si ces services sont disponibles à l'interface MPC distante. La station locale, effectue la même chose pendant ce temps avec les messages XID-1 reçus du MPC distant. A la fois les interfaces MPC locale et distante vérifient les champs d'intégrité et de sécurité du système dans les messages XID-1 reçus.
MPC distante valide également la taille et le sens des sous-canaux demandés afin de déterminer si ces services sont disponibles à l'interface MPC distante. La station locale, effectue la même chose pendant ce temps avec les messages XID-1 reçus du MPC distant. A la fois les interfaces MPC locale et distante vérifient les champs d'intégrité et de sécurité du système dans les messages XID-1 reçus.
Enfin, les différences dans les demandes de paramètres de manipulation de données sont résolues par des règles quelconques prescrites par l'application utilisateur. De façon caractéristique, cependant, les tailles de mémoire tampon et de voies de données sont toujours résolues en descendant vers la valeur demandée la plus basse. Une fois que les champs des messages XID-1 reçus sont validés et réglés, à la fois les interfaces MPC locale et distante construisent un message XID-2 d'essai afin de confirmer les valeurs des PARAM7TRES OPTIONNELS VARIABLES. Un nombre aléatoire créé localement pour chacun des messages XID-1 et inclus dans le message
XID-1 est utilisé afin de déterminer quelle interface MPC initialisera en fait le second échange de message (XID-2) de seconde phase. L'autre interface MPC sauvegarde le message XID-2 constitué jusqu'à ce qu'une comparaison puisse être faite lorsque le message
XID-2 est reçu de l'autre interface MPC.
XID-1 est utilisé afin de déterminer quelle interface MPC initialisera en fait le second échange de message (XID-2) de seconde phase. L'autre interface MPC sauvegarde le message XID-2 constitué jusqu'à ce qu'une comparaison puisse être faite lorsque le message
XID-2 est reçu de l'autre interface MPC.
Si le message XID-2 est reçu et validé avec succès dans l'interface MPC de réception, les deux messages XID-2 sont comparés afin de déterminer s'ils sont identiques. Si c'est le cas, le message XID-2 sauvegardé est émis vers l'interface MPC distante pour effectuer la validation et la comparaison à l'interface MPC distante. Enfin, si toutes les validations et comparaisons sont faites avec succès, les deux applications utilisateur sont prévenues de la conclusion réussie du processus d'identification d'échange et la transmission des données peut commencer. Si la validation échoue à un point quelconque du processus, le groupe de transmission requis est éliminé et l'interface MPC distante est prévenue de faire de même. Si une comparaison des messages XID-2 échoue, le message XID-2 créé localement est utilisé pour confirmation. Ce processus sera décrit plus en détail en liaison avec les figures 9 et 10.
Sur la figure 7 est représenté un organigramme de l'activation d'un groupe de canaux multi-voies par l'utilisation de messages XID similaires à ceux représentés sur les figures 5 et 6. Le processus de la figure 7 doit bien sûr, etre effectué en même temps pour chaque sous-canal du groupe de canaux multi-voies demandé. En partant du pavé de départ 110, on entre dans le pavé 111 dans lequel les voies sont allouées conformément à la demande de l'application utilisateur. De telles requêtes peuvent concerner des groupes de canaux multi-voies équilibrés ou non équilibrés correspondant, respectivement, au groupe de canaux multi-voies MPC1 62 et MPC2 65 de la figure 4. En fait, l'allocation de plus d'un groupe de canaux multi-voies peut etre demandée, et activée uniquement sur demande.
De telles allocations sélectionnent simplement et s'assurent de la disponibilité de sous-canaux de la taille et du sens demandés, mais n'établissent pas réellement les canaux multi-voies. Ainsi, dans le pavé 112, la validité des voies demandées est vérifiée. Enfin, dans le pavé 113, l'intégrité du système est vérifiée. Ainsi qu'on la noté ci-dessus, les champs d'identification de protocole, tels que le champ 93 sur la figure 5, peuvent comprendre des informations de sécurité telles que les identifications de système qui sont vérifiées pour déterminer si la transmission est autorisée ou non avec l'extrémité éloignée, c'est-à-dire de s'assurer que le groupe de canaux multi-voies demandé au périphérique ou système distant particulier est autorisable suivant des règles d'accès prédéterminées. Dans le pavé 114, les voies de transport demandées sont réellement activées, par exemple Valider pour la transmission.
Il est bien sûr également possible d'allouer les groupes de canaux multi-voies de façon statique par des déclarations du système, comme cela était effectué dans la technique antérieure, et simplement activer ces groupes de canaux pré-établis sur demande de l'utilisateur, comme cela était également courant dans la technique antérieure.
Une fois que les sous-canaux d'un groupe de transmission sont validés physiquement, un message (XID) d'identification d'échange ou plus est échangé entre les deux extrémités de chaque sous-canal afin de préparer l'émission des données utilisateur. Comme cela était présenté en liaison avec les figures 5 et 6, une partie de cet échange peut consister à déterminer le protocole utilisateur et à configurer les paramètres de transmission désirés tels que les tailles de mémoire tampon ou les tailles des voies. Une description plus détaillée de cet échange sera faite en liaison avec l'organigramme de la figure 10. Il est cependant important de noter, que cet échange prend place simultanément sur chaque sous-canal du groupe de canaux multi-voies demandés afin de s'assurer de la disponibilité et de l'identité des deux extrémités du sous-canal de transmission, de meme que des paramètres de transmission nécessaires qui sont demandés. On entre alors dans le pavé de décision 116 afin de déterminer si l'échange XID s'est terminé avec succès. Si ce n'est pas le cas, on entre dans le pavé 117 afin de notifier à l'application utilisateur que le groupe de canaux demandé ne sera pas activé pour la transmission des données. On entre alors dans le pavé 118 afin de désallouer les voies de transport établies dans le pavé 114 pour l'échange XID et le processus se termine dans le pavé final 119. On notera que cette désallocation nécessite un message de désallocation vers l'extrémité distante de l'ensemble de transmission afin de s'assurer de la désallocation à l'autre extrémité. Il est également important de noter que le processus d'activation représenté par l'organigramme de la figure 9 peut être initialisé à chaque extrémité du groupe de transmission et en fait, peut être initialisé simultanément aux deux extrémités du groupe de transmission.
Si l'échange XID se termine avec succès, comme cela est déterminé par le pavé de décision 116, on entre dans le pavé 120 dans lequel les processus de contrôle de transport 48 de l'interface
MPC de la figure 3 sont initialisés afin de renvoyer les tailles de mise en bloc requises et les protocoles de mise en bloc requis ou négociés avec l'extrémité éloignée du groupe de transmission. On entre alors dans le pavé 121 afin d'initialiser le gestionnaire de données MPC 45 (fig. 3) afin de renvoyer la taille de file d'attente 47 des données requises ou négociées, de même que le formatage des données 46 requis. On entre dans le pavé 122 afin d'affecter le sens de transmission requis sur le sous-canal de transmission particulier et on entre dans le pavé 123 afin de sélectionner la taille de bloc de transmission de ce sous-canal. On notera que les pavés 122 et 123 impliquent la capacité d'affecter dynamiquement à la fois le sens de transmission, de même que la capacité du sous-canal au moment de l'activation. Ceci constitue une contradiction complète avec la technique antérieure dans laquelle à la fois les sens de transmission et les tailles de sous-canaux étaient prédéterminés de façon statique et étaient simplement activés à l'instant de la demande de l'utilisateur. Il est important de noter que cette initialisation des processus d'interface MPC prend place simultanément à l'interface MPC distante en réponse à l'exécution correcte de l'échange XID.
MPC de la figure 3 sont initialisés afin de renvoyer les tailles de mise en bloc requises et les protocoles de mise en bloc requis ou négociés avec l'extrémité éloignée du groupe de transmission. On entre alors dans le pavé 121 afin d'initialiser le gestionnaire de données MPC 45 (fig. 3) afin de renvoyer la taille de file d'attente 47 des données requises ou négociées, de même que le formatage des données 46 requis. On entre dans le pavé 122 afin d'affecter le sens de transmission requis sur le sous-canal de transmission particulier et on entre dans le pavé 123 afin de sélectionner la taille de bloc de transmission de ce sous-canal. On notera que les pavés 122 et 123 impliquent la capacité d'affecter dynamiquement à la fois le sens de transmission, de même que la capacité du sous-canal au moment de l'activation. Ceci constitue une contradiction complète avec la technique antérieure dans laquelle à la fois les sens de transmission et les tailles de sous-canaux étaient prédéterminés de façon statique et étaient simplement activés à l'instant de la demande de l'utilisateur. Il est important de noter que cette initialisation des processus d'interface MPC prend place simultanément à l'interface MPC distante en réponse à l'exécution correcte de l'échange XID.
Lorsque toutes les variables de sous-canaux ont été sélectionnées et réalisées, on entre dans le pavé 124 dans lequel l'application utilisateur se voit notifier la disponibilité du groupe de canaux multi-voies demandé. On peut alors entrer dans le pavé 125 dans lequel l'application utilisateur transfère réellement les données vers l'emplacement distant sur le groupe de canaux alloué et activé. Le processus de la figure 9 se termine alors dans le bloc final 119. Bien qu'il ne soit pas décrit de façon explicite ici, un processus très similaire à celui représenté sur la figure 7 est utilisé pour désactiver et/ou désallouer le groupe de canaux multi-voies une fois que les transmissions de données sont terminées ou qu'une panne de transmission se produit.
En se référant plus particulièrement à la figure 8, est représenté un organigramme plus détaillé du processus d'échange de message XID qui prend place dans le pavé 115 de la figure 7. Sur la figure 10, en partant d'un pavé de départ 130, on entre dans le pavé 131 dans lequel la demande de l'utilisateur pour un groupe de canaux multi-voies est reçue. On notera que cette demande peut être reçue aux interfaces de canaux multi-voies (fig. 3) aux deux extrémités du groupe de canaux simultanément. Du fait que cette émission simultanée constitue le cas le plus difficile, on suppose dans l'organigramme de la figure 10 que les MPC aux deux extrémités du groupe de transmission font la demande d'activation du groupe de canaux multi-voies en même temps. Le format de message XID-1 est construit dans le pavé 132. Pour plus de facilité, on suppose que le format de message XID est celui représenté sur les figures 5 et 6. D'autres formats de message XID pourraient être utilisés à la place pour une autre application utilisateur d'une façon qui est évidente pour les personnes ayant des connaissance ordinaires de la technique.
Plus particulièrement, la taille de transmission du champ 98 est établie dans le pavé 132, de même que le sens de circulation des données dans le champ 97. Les informations d'intégrité du système appropriées sont fournies, lorsque souhaité, dans les champs 90 et 91 de la figure 5 et les champs 31 et 35 des en-têtes de la figure 2. De façon à résoudre l'ambiguité qui pourrait apparaitre à partir de l'émission simultanée d'un message XID-1 au MPC situé aux deux extrémités du groupe de canaux multi-voies, un signal de résolution dlambiguîté est introduit dans le champ de numéro de séquence 30 de l'en-tête de la figure 2. Ce signal de résolution d'ambiguité est un nombre généré de façon aléatoire dans le mode de réalisation d'illustration. Ce nombre aléatoire sera utilisé par l'interface MPC distante pour sélectionner lequel des messages XID-1 prendra le contrôle de la seconde face du processus d'activation. Une autre méthode pour résoudre une telle ambiguité comprend l'utilisation d'un tableau prédéfini d'ordre de priorité de paires terminales, disponibles aux deux extrémités de chaque groupe de canaux multivoies.
A la suite de la constitution du message XID-1 dans le pavé 132, on entre dans le pavé 133 dans lequel le message XID est émis sur chaque sous-canal à l'intérieur du groupe de canaux multi-voies alloué vers l'interface MPC distant. Dans le pavé 134, ce message
XID-1 est reçu à l'interface MPC distante et, dans le pavé 136, les paramètres du message XID-1 sont validés. C'est-à-dire que les signaux d'intégrité du système sont utilisés pour s'assurer de l'intégrité du système, que le sens de transmission pour ce souscanal et la taille du sous-canal sont utilisés pour s'assurer de la disponibilité du sous-canal et que le paramètre de mémoire tampon est utilisé pour déterminer si de telles possibilités sont disponibles. On entre alors dans le pavé 136 dans lequel le format d'un message XID-2 de seconde phase est constitué pour l'émission en retour vers l'interface MPC locale. Le format et le contenu des champs du message XID-2 sont identiques à ceux du message XID-1, à l'exception du paramètre de taille de mémoire tampon variable qui peut être modifié afin de renvoyer la disponibilité réelle de ces périphériques. On entre alors dans le pavé de décision 137 dans lequel il est évalué si les données du message XID-1 reçu à partir de l'interface MPC distante sont valides. Si les validations du pavé 135 sont toutes correctes, on entre dans le pavé 139 dans lequel le message XID-2 de deuxième phase est marqué comme étant @OK@8 dans dans le champ 94 (fig. 5). Si les validations échouent de quelque manière que ce soit dans le pavé 135, le message XID-2 de seconde phase est marqué comme étant "mauvais" (NG) dans le champ 94. Que le message
XID-1 reçu soit valide ou invalide, on entre dans le pavé de décision 140 dans lequel le nombre aléatoire du champ 30 (fig. 2) du nombre de segments d'en-téte XID-1 reçus est comparé au nombre aléatoire généré pour le message XID-1 émis localement. Si le nombre aléatoire reçu est de valeur plus élevée que le nombre aléatoire généré localement, on entre dans le pavé 141 et l'interface MPC distante attend de recevoir un message XID-2 de seconde phase de l'interface MPC distante. Lorsque cette réponse est reçue, on entre dans le pavé de décision 142 dans lequel le message
XID-2 de seconde phase reçu est validé, de la même manière que le message XID-1 d'origine était validé dans le pavé 135.
XID-1 est reçu à l'interface MPC distante et, dans le pavé 136, les paramètres du message XID-1 sont validés. C'est-à-dire que les signaux d'intégrité du système sont utilisés pour s'assurer de l'intégrité du système, que le sens de transmission pour ce souscanal et la taille du sous-canal sont utilisés pour s'assurer de la disponibilité du sous-canal et que le paramètre de mémoire tampon est utilisé pour déterminer si de telles possibilités sont disponibles. On entre alors dans le pavé 136 dans lequel le format d'un message XID-2 de seconde phase est constitué pour l'émission en retour vers l'interface MPC locale. Le format et le contenu des champs du message XID-2 sont identiques à ceux du message XID-1, à l'exception du paramètre de taille de mémoire tampon variable qui peut être modifié afin de renvoyer la disponibilité réelle de ces périphériques. On entre alors dans le pavé de décision 137 dans lequel il est évalué si les données du message XID-1 reçu à partir de l'interface MPC distante sont valides. Si les validations du pavé 135 sont toutes correctes, on entre dans le pavé 139 dans lequel le message XID-2 de deuxième phase est marqué comme étant @OK@8 dans dans le champ 94 (fig. 5). Si les validations échouent de quelque manière que ce soit dans le pavé 135, le message XID-2 de seconde phase est marqué comme étant "mauvais" (NG) dans le champ 94. Que le message
XID-1 reçu soit valide ou invalide, on entre dans le pavé de décision 140 dans lequel le nombre aléatoire du champ 30 (fig. 2) du nombre de segments d'en-téte XID-1 reçus est comparé au nombre aléatoire généré pour le message XID-1 émis localement. Si le nombre aléatoire reçu est de valeur plus élevée que le nombre aléatoire généré localement, on entre dans le pavé 141 et l'interface MPC distante attend de recevoir un message XID-2 de seconde phase de l'interface MPC distante. Lorsque cette réponse est reçue, on entre dans le pavé de décision 142 dans lequel le message
XID-2 de seconde phase reçu est validé, de la même manière que le message XID-1 d'origine était validé dans le pavé 135.
Si le message XID-2 reçu est identique au message XID-2 généré localement, le signal XID-2 généré localement est marqué comme étant "OK" dans le pavé 143 et émis vers l'interface MPC distante dans le pavé 144 pour achever le processus de confirmation. Si le nombre aléatoire est inférieur dans le message XID-1 généré localement, ou si la validation d'un message XID-2 reçu échoue dans le pavé de décision 142, on entre dans le pavé 148 dans lequel le message XID-2 est marqué comme étant mauvais ("NG") et on rentre à nouveau dans le pavé 144 pour émettre le message XID-2 vers l'interface MPC distante. On entre alors dans le pavé de décision 145 pour déterminer si à la fois les messages XID-2 générés localement et à distance sont corrects. Si c'est le cas, on entre dans le pavé 146 afin de notifier à l'utilisateur de démarrer l'émission des données utilisateur. Si ce n'est pas le cas, on entre dans le pavé 143 afin d'activer une procédure de panne comme décrit en liaison avec la figure 7. Dans les deux cas, on entre dans le pavé terminal 147 afin d'achever le processus d'échange XID de la figure 8 et de retourner au processus de la figure 7.
Bien que seuls deux échanges de messages XID soient décrits en liaison avec la figure 8, il est clair qu'un seul échange est nécessaire si aucun paramètre n'a besoin d'être négocié pour ce groupe de transmission. De façon similaire, si deux paramètres interdépendants ou plus ont besoin d'être négociés avant que le transfert de données ne puissent commencer, il est possible d'utiliser trois échanges XID ou plus pour réaliser ces négociations. De telles extensions ultérieures du processus d'échange XID sont évidentes aux personnes qui ont une connaissance normale de la technique et ne seront pas décrites davantage ici.
En se référant plus particulièrement à la figure 9, il est représenté un organigramme de la sous-indexation du segment de données en conformité avec la présente invention. En partant du pavé de départ 150, on entre dans le pavé 151 dans lequel un bloc de données local est mis en file d'attente dans l'interface MPC locale telle que l'interface 12 de la figure 1 et représentée plus en détail sur la figure 3. On suppose que l'échange de message XID s'est déjà déroulé avec succès entre une interface MPC locale 61 (fig. 4) et une interface MPC distante 72 pour tous les sous-canaux 66 à 69 du groupe de transmission MPC2 65 à 80. Pour ce qui concerne l'organigramme de la figure 9, on suppose que les sous-canaux d'écriture C et D (66 à 75, et 67 à 76 de la figure 3) ont une capacité de 4 kilooctets et ne peuvent de ce fait prendre que des segments de données jusqu'à une longueur de 4 kilooctets. Le souscanal d'écriture E (68 à 77 de la figure 3), par contre, présente une capacité de 16 kilooctets et peut de ce fait accepter des segments de données jusqu'à une longueur de 16 kilooctets. On supp bien sur réalisées de façon symétrique pour des transmissions en sens opposé.
En revenant à la figure 9, le pavé 152 formate un segment de données de 16 kilooctets pour l'émission sur la voie E, alors que les pavés 153 et 154 formatent chacun un segment de données de 4 kilooctets pour l'émission sur les voies B et C, respectivement. On suppose sur la figure 11 que les segments de 4 kilooctets émis sur les voies C et D sont reçus avec succès au MPC distant dans les pavés 155 et 156, respectivement. Le segment de 16 kilooctets émis sur la voie E, cependant, est perdu d'une manière quelconque (par exemple, par la panne de la voie du canal 70 de la figure 4), comme cela est détecté au pavé 157 par l'interface MPC distante. Si le segment émis sur la voie E est perdu, comme cela est détecté au pavé 157, on entre dans le pavé 158 afin de désallouer la voie E à l'interface MPC éloignée. Du fait qu'une panne quelconque s'est produite sur la voie E, il est important de mettre cette voie horsservice, non seulement pour ce groupe de canaux multi-voies, mais pour tous les groupes de canaux définis précédemment.
Le canal représenté sur la figure 4 comme étant le canal B (74 à 64 sur la figure 4) présentera un état d'erreur indiquant une panne de voies et identifiant la voie E, tout ceci en conformité avec le système de détection de panne de la technique antérieure.
A l'interface MPC locale, au pavé 173, la voie E est désallouée à l'interface MPC locale en réponse à ce message de panne. Egalement en réponse au message de panne, on entre dans le pavé de réémission 161 dans lequel le segment de données perdu est réémis vers l'interface MPC distante. Cependant, du fait que le sous-canal E à 16 kilooctets n'est plus disponible dans le groupe de transmission
MPC2, le segment de données à 16 kilooctets doit être rompu en quatre segments de données à 4 kilooctets de telle manière qu'il puisse être transmis sur les deux sous-canaux disponibles à 4 kilooctets identifiés sous le nom de voies C et D. Conformément à la présente invention, quatre sous-segments de 4 kilooctets sont formés à partir du segment à seize kilooctets original aux pavés 162, 163, 164 et 165. Chacun de ces sous-segments à quatre kilooctets présente un numéro de segment ajouté au champ 32 de l'entête 25 (fig. 2) du bloc de transmission.
MPC2, le segment de données à 16 kilooctets doit être rompu en quatre segments de données à 4 kilooctets de telle manière qu'il puisse être transmis sur les deux sous-canaux disponibles à 4 kilooctets identifiés sous le nom de voies C et D. Conformément à la présente invention, quatre sous-segments de 4 kilooctets sont formés à partir du segment à seize kilooctets original aux pavés 162, 163, 164 et 165. Chacun de ces sous-segments à quatre kilooctets présente un numéro de segment ajouté au champ 32 de l'entête 25 (fig. 2) du bloc de transmission.
On notera que les trois segments de données formés aux pavé 152, 153 et 154 comprennent des numéros de séquence dans le champ 30 de l'en-tête 25 du bloc de transmission de données qui transporte ces segments de données. Le but de ces numéros de séquence dans le champ 30 est de permettre à l'interface MPC distante de réassembler ces segments de données dans l'ordre approprié dans le cas où il serait délivré à l'interface MPC distante sous un autre ordre quelconque à cause d'anomalies de retard sur les voies de canaux physiques variables sur lesquelles les sous-canaux sont obtenus. Les numéros de segment des blocs réémis aux pavés 162 à 165 remplissent la même fonction pour le segment de données réémis resegmenté. C'est-à-dire que si les quatre sous-segments générés dans les pavés 162 à 165 arrivent à l'interface MPC distante dans un ordre autre que l'ordre originellement émis, les numéros de segment permettent à l'interface
MPC distante de réassembler les sous-segments dans l'ordre approprié pour les délivrer à l'utilisateur final. On notera que le numéro de séquence original doit être conservé dans le champ 30 de numéro de séquence (fig. 2) afin d'assurer une mise en ordre appropriée des segments originaux.
MPC distante de réassembler les sous-segments dans l'ordre approprié pour les délivrer à l'utilisateur final. On notera que le numéro de séquence original doit être conservé dans le champ 30 de numéro de séquence (fig. 2) afin d'assurer une mise en ordre appropriée des segments originaux.
Les numéros de séquence utilisés pour ordonner de façon appropriée les segments de données lors d'une transmission de données segmentée, sont quelquefois appelés indices de segment et le processus appelé indexation de segment. L'indexation de second niveau décrite ci-dessus peut, de ce fait, etre appelée sousindexation de segments de données resegmentés, et réémis. En supposant que les sous-segments de données resegmentés réémis soient tous reçus avec succès à l'interface MPC distante, comme indiqué par les pavés 166, 167, 168 et 169, les numéros de séquence peuvent etre utilisés pour réassembler les trois segments originaux au pavé 170.
En même temps, les numéros de segment des sous-segments réémis resegmentés du segment à seize kilooctets formé au pavé 152 et resegmenté dans les pavés 162 à 165 sont utilisés pour réassembler de façon appropriée les sous-segments en un nouveau segment à seize kilooctets qui, à son tour, est assemblé en blocs de données d'origine au pavé 170. Le bloc de données réassemblé est alors délivré à l'application utilisateur distante au pavé 171 et le processus de la figure 11 se termine dans le pavé terminal 172.
Claims (8)
1. Sous-système de transmission d'entrée et de sortie pour un système d'ordinateur numérique d'usage général comprenant
au moins une application utilisateur fonctionnant dans ledit système d'ordinateur suivant un protocole de transmission prédéterminé afin de communiquer des blocs de données à un système d'utilisation de données distant sur un canal de transmission comportant une pluralité de sous-canaux de capacité de transmission limitée,
un moyen pour segmenter lesdits blocs de données en segments pour leur émission sur les sous-canaux choisis parmi les sous-canaux présentant une capacité de transmission égale ou inférieure à chacun desdits segments,
un moyen dans ledit moyen de segmentation pour procurer un numéro de segment à chacun desdits segments afin d'identifier la séquence appropriée dudit chaque segment,
un moyen qui répond à une panne de l'un desdits sous-canaux présentant une capacité de transmission supérieure à au moins un autre desdits sous-canaux afin de resegmenter les segments émis sur ledit un sous-canal en panne en sous-segments pour leur émissions sur lesdits au moins un autre sous-canal, et
un moyen pour ajouter le numéro de séquence à chacun desdits sous-segments resegmentés afin de faciliter le réassemblage desdits sous-segments en ledit segment resegmenté.
2. Sous-système de transmission d'entrée et de sortie selon la revendication 1 comprenant en outre
un moyen pour désallouer ledit sous-canal en panne audit système d'ordinateur et audit système d'utilisation de données.
3. Sous-système de transmission d'entrée et de sortie selon la revendication 1 ou 2 comprenant en outre
un moyen pour réassembler lesdits segments et sous-segments en ledit bloc d'informations tel que procuré par ladite application utilisateur en utilisant lesdits numéros de segment et de séquence.
4. Sous-système de transmission d'entrée et de sortie selon la revendication 1, 2 ou 3 comprenant en outre
un moyen pour allouer dynamiquement auxdits sous-canaux une capacité de transmission déterminée dynamiquement et un sens de transmission déterminé dynamiquement.
5. Procédé pour les transmissions d'entrée et de sortie pour un système d'ordinateur numérique d'usage général comprenant les étapes consistant à
faire fonctionner au moins une application utilisateur dans ledit système d'ordinateur suivant un protocole de transmission prédéterminé afin de communiquer des blocs de données à un système d'utilisation de données distant sur un canal de transmission présentant une pluralité de sous-canaux de capacité de transmission limité,
segmenter lesdits blocs de données en segments pour leur émission sur les sous-canaux choisis parmi lesdits sous-canaux présentant une capacité de transmission égale ou inférieure à chacun desdits segments,
procurer, dans ledit moyen pour segmenter, un numéro de segment à chacun desdits segments afin d'identifier la séquence appropriée dudit chaque segment,
resegmenter, en réponse à une panne de l'un desdits sous-canaux présentant une capacité de transmission supérieure à au moins un autre desdits sous-canaux, les segments transmis sur ledit un sous canal en panne en sous-segments pour leur émission sur ledit au moins un autre sous-canal, et
ajouter des numéros de séquence à chacun desdits sous-segments resegmentés afin de faciliter le réassemblage desdits sous-segments en ledit segment resegmenté.
6. Procédé selon la revendication 5 comprenant en outre l'étape de désallocation dudit sous-canal en panne audit système d'ordinateur et audit système d'utilisation de données.
7. Procédé selon la revendication 5 ou 6 comprenant en outre l'étape de réassemblage auxdits segments et sous-segments en ledit bloc d'informations tel que procuré par ladite application utilisateur en utilisant lesdits numéros de segment et de séquence.
8. Procédé selon la revendication 5, 6 ou 7 comprenant en outre l'étape consistant à allouer dynamiquement lesdits sous-canaux en capacité de transmission déterminée dynamiquement et en sens de transmission déterminé dynamiquement.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US25201994A | 1994-06-01 | 1994-06-01 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2719681A1 true FR2719681A1 (fr) | 1995-11-10 |
Family
ID=22954289
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9505303A Pending FR2719681A1 (fr) | 1994-06-01 | 1995-04-27 | Interfaces de canal améliorées pour des canaux d'entrée/sortie d'ordinateur. |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US5805822A (fr) |
| JP (1) | JP3172387B2 (fr) |
| FR (1) | FR2719681A1 (fr) |
Families Citing this family (63)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6226678B1 (en) * | 1995-09-25 | 2001-05-01 | Netspeak Corporation | Method and apparatus for dynamically defining data communication utilities |
| JP3605242B2 (ja) * | 1996-11-12 | 2004-12-22 | 富士通株式会社 | データ送信装置、データ受信装置、およびデータファイル記憶媒体 |
| US6122276A (en) * | 1997-06-30 | 2000-09-19 | Cisco Technology, Inc. | Communications gateway mapping internet address to logical-unit name |
| US6167466A (en) | 1997-07-09 | 2000-12-26 | Texas Instruments Incorporated | Multi-channel serial port with programmable features |
| US6128662A (en) * | 1997-08-29 | 2000-10-03 | Cisco Technology, Inc. | Display-model mapping for TN3270 client |
| US6049833A (en) * | 1997-08-29 | 2000-04-11 | Cisco Technology, Inc. | Mapping SNA session flow control to TCP flow control |
| US6105068A (en) * | 1998-02-10 | 2000-08-15 | 3Com Corporation | Method and apparatus for determining a protocol type on a network connection using error detection values stored within internetworking devices |
| US6148004A (en) * | 1998-02-11 | 2000-11-14 | Mcdata Corporation | Method and apparatus for establishment of dynamic ESCON connections from fibre channel frames |
| US6341129B1 (en) * | 1998-04-03 | 2002-01-22 | Alteon Networks, Inc. | TCP resegmentation |
| US6249213B1 (en) * | 1998-12-17 | 2001-06-19 | Intel Corporation | Method for transmitting information over an alternating current power line through a plurality of frequency orthogonal subchannels |
| US6728210B1 (en) * | 1998-12-21 | 2004-04-27 | Nec America, Inc. | Multi-logical access for a serial data link |
| KR20000075358A (ko) * | 1999-05-27 | 2000-12-15 | 윤종용 | 이동통신시스템에서 라디오링크프로토콜에 따른 가변길이의 데이터 송수신 장치 및 방법 |
| US6813663B1 (en) | 1999-11-02 | 2004-11-02 | Apple Computer, Inc. | Method and apparatus for supporting and presenting multiple serial bus nodes using distinct configuration ROM images |
| US6457086B1 (en) * | 1999-11-16 | 2002-09-24 | Apple Computers, Inc. | Method and apparatus for accelerating detection of serial bus device speed signals |
| US6639918B1 (en) | 2000-01-18 | 2003-10-28 | Apple Computer, Inc. | Method and apparatus for border node behavior on a full-duplex bus |
| US7266617B1 (en) | 2000-01-18 | 2007-09-04 | Apple Inc. | Method and apparatus for border node behavior on a full-duplex bus |
| US6757273B1 (en) * | 2000-02-07 | 2004-06-29 | Nokia Corporation | Apparatus, and associated method, for communicating streaming video in a radio communication system |
| US7050453B1 (en) | 2000-02-17 | 2006-05-23 | Apple Computer, Inc. | Method and apparatus for ensuring compatibility on a high performance serial bus |
| US6618785B1 (en) * | 2000-04-21 | 2003-09-09 | Apple Computer, Inc. | Method and apparatus for automatic detection and healing of signal pair crossover on a high performance serial bus |
| US7826384B2 (en) * | 2000-05-04 | 2010-11-02 | Nortel Networks Limited | Method and apparatus for negotiating bearer control parameters using property sets |
| US6862430B1 (en) * | 2000-07-05 | 2005-03-01 | Echelon Corporation | System and method for selecting repeaters |
| US8881193B2 (en) * | 2001-07-20 | 2014-11-04 | Intel Corporation | Method and apparatus for enhancing television programs with event notifications |
| US6915450B2 (en) | 2001-11-01 | 2005-07-05 | Sun Microsystems, Inc. | Method and apparatus for arbitrating transactions between domains in a computer system |
| US7096236B2 (en) * | 2001-11-06 | 2006-08-22 | Sun Microsystems, Inc. | Change sequence number generator |
| US8233501B2 (en) * | 2002-02-13 | 2012-07-31 | Interdigital Technology Corporation | Transport block set segmentation |
| US7353284B2 (en) * | 2003-06-13 | 2008-04-01 | Apple Inc. | Synchronized transmission of audio and video data from a computer to a client via an interface |
| US7356613B2 (en) * | 2004-08-17 | 2008-04-08 | International Business Machines Corporation | Routable application partitioning |
| US8171238B1 (en) | 2007-07-05 | 2012-05-01 | Silver Peak Systems, Inc. | Identification of data stored in memory |
| US8392684B2 (en) | 2005-08-12 | 2013-03-05 | Silver Peak Systems, Inc. | Data encryption in a network memory architecture for providing data based on local accessibility |
| US8095774B1 (en) | 2007-07-05 | 2012-01-10 | Silver Peak Systems, Inc. | Pre-fetching data into a memory |
| US8489562B1 (en) | 2007-11-30 | 2013-07-16 | Silver Peak Systems, Inc. | Deferred data storage |
| US8811431B2 (en) | 2008-11-20 | 2014-08-19 | Silver Peak Systems, Inc. | Systems and methods for compressing packet data |
| US8929402B1 (en) | 2005-09-29 | 2015-01-06 | Silver Peak Systems, Inc. | Systems and methods for compressing packet data by predicting subsequent data |
| US8885632B2 (en) | 2006-08-02 | 2014-11-11 | Silver Peak Systems, Inc. | Communications scheduler |
| US8755381B2 (en) | 2006-08-02 | 2014-06-17 | Silver Peak Systems, Inc. | Data matching using flow based packet data storage |
| US8165162B2 (en) * | 2006-10-24 | 2012-04-24 | Broadcom Corporation | Method and system for optimizing fragment size for aggregation at the physical layer |
| US8768895B2 (en) * | 2007-04-11 | 2014-07-01 | Emc Corporation | Subsegmenting for efficient storage, resemblance determination, and transmission |
| US8694662B2 (en) * | 2007-07-10 | 2014-04-08 | Qualcomm Incorporated | Method and apparatus for communicating transmission requests to members of a group and/or making group related transmission decisions |
| US8861418B2 (en) * | 2007-07-10 | 2014-10-14 | Qualcomm Incorporated | Methods and apparatus for supporting group communications with data re-transmission support |
| US8495232B2 (en) * | 2007-07-10 | 2013-07-23 | Qualcomm Incorporated | Methods and apparatus for supporting broadcast communications in a peer to peer network |
| US7961698B2 (en) * | 2007-07-10 | 2011-06-14 | Qualcomm Incorporated | Methods and apparatus for controlling interference to broadcast signaling in a peer to peer network |
| US8307115B1 (en) | 2007-11-30 | 2012-11-06 | Silver Peak Systems, Inc. | Network memory mirroring |
| US9717021B2 (en) | 2008-07-03 | 2017-07-25 | Silver Peak Systems, Inc. | Virtual network overlay |
| US10164861B2 (en) | 2015-12-28 | 2018-12-25 | Silver Peak Systems, Inc. | Dynamic monitoring and visualization for network health characteristics |
| US8743683B1 (en) | 2008-07-03 | 2014-06-03 | Silver Peak Systems, Inc. | Quality of service using multiple flows |
| US10805840B2 (en) | 2008-07-03 | 2020-10-13 | Silver Peak Systems, Inc. | Data transmission via a virtual wide area network overlay |
| CN101938406B (zh) * | 2009-07-02 | 2012-07-04 | 华为技术有限公司 | 微波多通道报文发送方法和装置及传送系统 |
| US9130991B2 (en) * | 2011-10-14 | 2015-09-08 | Silver Peak Systems, Inc. | Processing data packets in performance enhancing proxy (PEP) environment |
| US9626224B2 (en) | 2011-11-03 | 2017-04-18 | Silver Peak Systems, Inc. | Optimizing available computing resources within a virtual environment |
| JP5845462B2 (ja) * | 2011-11-07 | 2016-01-20 | パナソニックＩｐマネジメント株式会社 | 通信システムおよびそれに用いる伝送ユニット |
| IN2013MU01356A (fr) | 2012-04-11 | 2015-07-10 | Hughes Network Systems Llc | |
| US8929400B2 (en) | 2013-02-10 | 2015-01-06 | Hughes Network Systems, Llc | Apparatus and method for support of communications services and applications over relatively low signal-to-noise ratio links |
| US8964896B2 (en) | 2013-05-16 | 2015-02-24 | Hughes Network Systems, Llc | PLS header coding for efficient signaling of modulation and coding schemes for broadband satellite communications systems |
| US9948496B1 (en) | 2014-07-30 | 2018-04-17 | Silver Peak Systems, Inc. | Determining a transit appliance for data traffic to a software service |
| US9875344B1 (en) | 2014-09-05 | 2018-01-23 | Silver Peak Systems, Inc. | Dynamic monitoring and authorization of an optimization device |
| US10432484B2 (en) | 2016-06-13 | 2019-10-01 | Silver Peak Systems, Inc. | Aggregating select network traffic statistics |
| US9967056B1 (en) | 2016-08-19 | 2018-05-08 | Silver Peak Systems, Inc. | Forward packet recovery with constrained overhead |
| US10771394B2 (en) | 2017-02-06 | 2020-09-08 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows on a first packet from DNS data |
| US10892978B2 (en) | 2017-02-06 | 2021-01-12 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows from first packet data |
| US10257082B2 (en) | 2017-02-06 | 2019-04-09 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows |
| US11044202B2 (en) | 2017-02-06 | 2021-06-22 | Silver Peak Systems, Inc. | Multi-level learning for predicting and classifying traffic flows from first packet data |
| US11212210B2 (en) | 2017-09-21 | 2021-12-28 | Silver Peak Systems, Inc. | Selective route exporting using source type |
| US10637721B2 (en) | 2018-03-12 | 2020-04-28 | Silver Peak Systems, Inc. | Detecting path break conditions while minimizing network overhead |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0148297A1 (fr) * | 1984-01-09 | 1985-07-17 | Hitachi, Ltd. | Système de traitement décentralisé synchrone |
| WO1988001410A2 (fr) * | 1986-08-21 | 1988-02-25 | Licentia Patent-Verwaltungs-Gmbh | Procede et dispositif pour transmettre, de maniere fiable sur le plan de la technique de signalisation, des donnees serielles entre des ordinateurs fiables travaillant de preference sur deux canaux, au moyen d'un systeme de bus a double boucle |
| JPH01137736A (ja) * | 1987-11-24 | 1989-05-30 | Canon Inc | フアクシミリ装置 |
| US5084816A (en) * | 1987-11-25 | 1992-01-28 | Bell Communications Research, Inc. | Real time fault tolerant transaction processing system |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB1559897A (en) * | 1977-03-15 | 1980-01-30 | Post Office | Multiplexing speech |
| NL8300033A (nl) * | 1983-01-06 | 1984-08-01 | Philips Nv | Werkwijze voor het overdragen van digitale informatie over een transmissiering. |
| US4658152A (en) * | 1985-12-04 | 1987-04-14 | Bell Communications Research, Inc. | Adaptive rate multiplexer-demultiplexer |
| US4941089A (en) * | 1986-12-12 | 1990-07-10 | Datapoint Corporation | Input/output network for computer system |
| US4745599A (en) * | 1987-01-05 | 1988-05-17 | General Electric Company | Random access communication system with contention scheduling of subpacketized data transmissions and scheduled retransmission of unsuccessful subpackets |
| US5109483A (en) * | 1987-06-15 | 1992-04-28 | International Business Machines Corp. | Node initiating xid exchanges over an activated link including an exchange of sets of binding signals between nodes for establishing sessions |
| US4843541A (en) * | 1987-07-29 | 1989-06-27 | International Business Machines Corporation | Logical resource partitioning of a data processing system |
| JP2845889B2 (ja) * | 1988-05-16 | 1999-01-13 | 株式会社日立製作所 | 衛星通信方式及び衛星通信システム |
| JPH0216827A (ja) * | 1988-07-04 | 1990-01-19 | Omron Tateisi Electron Co | データ伝送装置 |
| US5138615A (en) * | 1989-06-22 | 1992-08-11 | Digital Equipment Corporation | Reconfiguration system and method for high-speed mesh connected local area network |
| US5181017A (en) * | 1989-07-27 | 1993-01-19 | Ibm Corporation | Adaptive routing in a parallel computing system |
| JPH0687569B2 (ja) * | 1989-09-28 | 1994-11-02 | アメリカン テレフォン アンド テレグラフ カムパニー | 端末アダプタおよびデータ伝送方法 |
| US5005170A (en) * | 1990-01-09 | 1991-04-02 | At&T Bell Laboratories | Multi-rate multiplexing arrangement efficiently utilizing multiplexed channel bandwidth |
| US5206933A (en) * | 1990-03-15 | 1993-04-27 | International Business Machines Corporation | Data link controller with channels selectively allocatable to hyper channels and hyper channel data funneled through reference logical channels |
| US5367643A (en) * | 1991-02-06 | 1994-11-22 | International Business Machines Corporation | Generic high bandwidth adapter having data packet memory configured in three level hierarchy for temporary storage of variable length data packets |
| WO1993026109A1 (fr) * | 1992-06-17 | 1993-12-23 | The Trustees Of The University Of Pennsylvania | Appareil assurant le support cryptographique dans un reseau |
| US5305104A (en) * | 1992-07-27 | 1994-04-19 | The Trustees Of Columbia University In The City Of New York | Digitally assisted motion compensated deinterlacing for enhanced definition television |
| US5546549A (en) * | 1994-06-01 | 1996-08-13 | International Business Machines Corporation | Multi-path channel (MPC) interface with user transparent, unbalanced, dynamically alterable computer input/output channels |
-
1995
- 1995-03-20 JP JP06051695A patent/JP3172387B2/ja not_active Expired - Fee Related
- 1995-04-27 FR FR9505303A patent/FR2719681A1/fr active Pending
-
1996
- 1996-12-23 US US08/772,478 patent/US5805822A/en not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0148297A1 (fr) * | 1984-01-09 | 1985-07-17 | Hitachi, Ltd. | Système de traitement décentralisé synchrone |
| WO1988001410A2 (fr) * | 1986-08-21 | 1988-02-25 | Licentia Patent-Verwaltungs-Gmbh | Procede et dispositif pour transmettre, de maniere fiable sur le plan de la technique de signalisation, des donnees serielles entre des ordinateurs fiables travaillant de preference sur deux canaux, au moyen d'un systeme de bus a double boucle |
| JPH01137736A (ja) * | 1987-11-24 | 1989-05-30 | Canon Inc | フアクシミリ装置 |
| US5084816A (en) * | 1987-11-25 | 1992-01-28 | Bell Communications Research, Inc. | Real time fault tolerant transaction processing system |
Non-Patent Citations (1)
| Title |
|---|
| PATENT ABSTRACTS OF JAPAN vol. 13, no. 390 (E - 813) 29 August 1989 (1989-08-29) * |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH07325767A (ja) | 1995-12-12 |
| JP3172387B2 (ja) | 2001-06-04 |
| US5805822A (en) | 1998-09-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2719681A1 (fr) | Interfaces de canal améliorées pour des canaux d'entrée/sortie d'ordinateur. | |
| US5546549A (en) | Multi-path channel (MPC) interface with user transparent, unbalanced, dynamically alterable computer input/output channels | |
| EP0349371B1 (fr) | Système informatique à interconnexion centrale | |
| EP0062960B1 (fr) | Procédé de gestion de l'émission-réception de données dans un réseau local de communication et système de transmission de données pour l'application du procédé | |
| EP0755010B1 (fr) | Dispositif d'interface entre un calculateur à architecture redondante et un moyen de communication | |
| US8396981B1 (en) | Gateway for connecting storage clients and storage servers | |
| CA2052428A1 (fr) | Pont pour relier un reseau local, conforme a la norme ieee 802.3, a un reseau de telecommunications a technique temporelle asynchrone | |
| EP0046831A1 (fr) | Système de retransmission de trames numérotées et reçues en erreur dans un système de transmission de données | |
| FR2832011A1 (fr) | Reseau de communication de type ethernet full duplex commute et procede de mise en oeuvre de celui-ci | |
| FR2579342A1 (fr) | Reseau local de transmission de donnees et procede d'affectation automatique d'adresses a des dispositifs de traitement de donnees de ce reseau | |
| FR2579341A1 (fr) | Reseau local de transmission de donnees comportant un systeme de detection de signaux, evitant des collisions et procede de transfert de donnees dans un tel reseau | |
| US7647460B1 (en) | Method and apparatus for implementing a remote mirroring data facility without employing a dedicated leased line to form the link between two remotely disposed storage devices | |
| EP1997295A2 (fr) | Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede | |
| WO2013030505A1 (fr) | Procédé d'échange de données entre noeuds d'une grappe de serveurs et grappe de serveurs mettant en oeuvre ce procédé | |
| FR2863073A1 (fr) | Dispositif et procede de controle d'acces | |
| FR2862776A1 (fr) | Adaptateur de canal et dispositif de reseau de disques | |
| EP2497235B1 (fr) | Outil de diagnostic pour réseaux à haut débit | |
| EP1520378B1 (fr) | Systeme et procede de gestion sur un terminal de l architect ure dediee a un reseau de communication | |
| EP0932271B1 (fr) | Procédé de communication avec acquittement de réception amélioré | |
| EP0866410B1 (fr) | Système informatique à stockage de données distribué | |
| JP3130226B2 (ja) | 入出力通信サブシステム及び方法 | |
| BE1004536A6 (fr) | Transmission de donnees et controle d'acces a celles-ci. | |
| CN110177151A (zh) | 一种点对点数据传输方法、系统、接收设备及发送设备 | |
| FR2867641A1 (fr) | Systeme de memorisation a tolerance de pannes a architecture d'interconnexion qui assure egalement le trafic du reseau | |
| EP0675618A1 (fr) | Dispositif d'adaptation entre un réseau temporel synchrone et un réseau temporel asynchrone |