L'adaptation s'est faite sans trop de problèmes pour le premier couple de programme : cli_fork et serv_fork.
Les sources sont disponibles : cli_fork.c et serv_fork.c
Le schéma de fonctionnement est simple, le serveur (serv_fork) écoute sur un SAP. Puis le client (cli_fork) se connecte sur ce SAP, et envoie au serveur les caractères tapés au clavier. Ici, la connexion utilisée est bi-directionnelle (dataflow = duplex). En effet, le serveur envoie au début et à la fin de la connexion un message au client (qui est affiché à l'écran).
Le premier problème rencontré
est le suivant :
En IP, lorsque l'on a une connexion bi-directionnelle, on peut fermer l'une
des directions par la commande shutdown. C'est ce que fait le
client dans la version IP du programme. Le serveur est alors averti que la
connexion est fermée dans le sens client->serveur car la commande
read renvoie la valeur 0. Il envoie donc un dernier message au
client, puis ferme la connexion TCP.
En ATM, la fonction shutdown ne fonctionne pas. Ainsi, le serveur
reste bloqué sur la fonction atm_recv qui attend des données.
Il ne se rend donc pas compte que la connexion est fermée dans le sens
client->serveur, et n'envoie donc pas le dernier message qu'attend le client
: DEADLOCK. Les deux programmes sont plantés...
Il y a un réel problème pour la fermeture de la connexion. La seule fonction qui permette de faire cela est atm_close. Le problème est qu'elle le fait brutalement, sans avertir l'autre coté. En face, la prochaine tentative de lecture (ou d'écriture) de données à travers de la connexion échoue, avec le message "connexion reset by peer". Il faut alors intercepter l'erreur, est vérifier que c'est bien cette erreur là qui s'est produite, et pas une autre. On conclut alors que la connexion a été fermée par l'autre programme.
Pour cela, il faut essayer de récuperer le numéro
de l'erreur. Les fonction atm_send
et atm_recv renvoient une
valeur qui est toujours -1 en cas d'erreur. Il existe cependant une variable
de l'API, nommée atm_errno
qui est censée contenir le numéro de l'erreur. Or elle contient
aussi toujours la valeur -1. Heureusement, la variable classique errno
change elle de valeur ! Nous avons donc pu récuperer le numéro
de l'erreur quand la connexion était femée par la machine distante,
et utiliser cette valeur pour faire le test (voir
atm_errno pour la liste des valeur qui nous ont été utiles).
Le programme adapté du TP Socket fonctionne correctement (aux différences près dues à la fermeture de la connexion). Il n'y a rien de spécial à dire dessus.
Les connexions ATM n'offrent pas les mêmes fonctions que
les sockets en IP. Par exemple, les fonctions select ou shutdown
ne marchent pas. De même, les fonctions atm_recv
et atm_send n'offrent pas
les mêmes fonctionnalités que read et write.
C'est pourquoi nous n'avons pas pu porter les autres TP Sockets en ATM natif.