du type Client/Serveur Cette page a pour but d'expliquer toutes les opérations à effectuer pour établir une connexion en mode ATM natif entre deux machines. La machine appelante sera appelée client, la machine recevant l'appel sera nommée serveur.
Client |
Serveur |
|---|---|
| Pour le client, comme pour le serveur on utilisera l'include spécifique des cartes FORE:
en utilisant à la compilation:
info est une structure de type Atm_info définie dans le header fore_atm_user.h:
Ouverture du device représentant la carte ATM (pour les cartes FORE System, le device est "/dev/fa0") |
|
|
Activation d'un SAP (Service Access Point):
|
|
|
Récupération de l'adresse ATM du serveur
|
Attente d'une demande de connexion sur le SAP.
On attends ensuite une demande de connexion d'un client. |
|
Choix du SAP du serveur;
Le SAP est l'équivalent du port en IP. |
Attente... |
|
Choix de la qualité de service demandée :
Le client remplit la structure Qos :
qos.peak_bandwidth.target = 1000; ces valeurs, prises arbitrairement ici, sont exprimées en Kbits/s |
|
|
Demande d'ouverture de la connexion:
On reçoit en retour la qualité de service réellement obtenue. |
Une demande de connexion arrive.
Les variables conn_id, calling, qos et aal permettent au serveur de
connaître quelques détails sur la demande de connexion.
|
| Attente... |
Acceptation de la connexion.
Le serveur accepte la connexion, en ayant le dernier mot sur la QOS de cette connexion. |
|
Retour de la commande atm_connect.
On peut vérifier par la variable qos_selected la QOS
réellement obtenue.
|
Réception des données: |
|
Fermeture de la connexion:
La connexion est fermée par une commande : de n'importe laquelle des machines. L'autre machine reçoit alors un message d'erreur ("Connection reset by peer") lui indiquant que la machine distante vient de fermer la connexion. Il lui reste alors à refermer le device par: |
|
L'AAL 3/4 et 5 seront les plus utilisées, car elle permettent un transfert fiable et simple à utiliser (comme TCP en IP). On imagine difficilement l'utilisation de l'AAL nulle. Ses capacitées se rapprochent de l'UDP en IP, c'est à dire le transfert non fiable d'une seule cellule ATM (48 octets de charge utile). Elle n'implémente pas de contrôle d'erreur, ni de contrôle de flux. Le seul intérêt de l'UDP, c'est à dire la légèreté du protocole, et ici perdue, puisqu'il faut quand même ouvrir une connexion ATM pour pouvoir envoyer une seule cellule, et ce sans aucune garantie...
Entre les AAL 3/4 et l'AAL 5, les différences sont minimes. On préférera donc utiliser l'AAL5 dans les application car sa gestion est plus simple (dixit le poly sur l'ATM).
L'AAL null dispose de fonctions dédiées, qui permettent d'effectuer des opération avancées (comme spécifier ou récuperer le header d'une cellule). Ces fonctions ne nous ont pas du tout servies, et ne sont donc pas citées ici. Son utilisation est aussi plus délicate, puisqu'il faut fournir des cellules entières pour les envoyer (et donc gérer l'eventuel bourrage de la cellule).