Page précédente Page suivante Table des matières

4. Le serveur rdeviced

Pour l'instant, les messages d'erreur du serveur sont envoyés sur stderr, il sera judicieux de modifier les sources pour les envoyers dans les fichiers log du système. Encore une fois, seul le résultat compte, la forme importe peu pour l'instant. Mon but est avant tout de valider la faisabilité du truc.

Pour faire les tests, je lance le serveur de la manière suivante:


$ rdeviced &

Bien entendu plus tard il faudra le lancer soit via inetd, soit depuis un fichier de démarrage.

Du fait que les variables utilisées sont statiques, il y a peu de chance que le serveur accepte des requêtes concurrentes pour l'instant, là encore ce n'est pas important dans un premier temps.

Si dans votre client vous ne refermez pas le périphérique que vous ouvrez, il vaut mieux tuer le serveur et le relancer, plus tard il faudra essayer de détecter ce type de problème.

Il y a plusieurs améliorations à apporter au serveur, notamment la possibilité de transmettre au client des signaux. J'ai vu quelque part que les routines callback existaient en langage RPC mais je ne retrouve plus le document.

Ensuite il faudrait ajouter une fonction de verrouillage automatique des périphériques, comme avec uucp, cette fonction serait appelée par la fonction d'ouverture et le verrou serait effacé par la fonction de fermeture.

Le serveur rdeviced est utilisable tel quel, mais il peut servir de squelette à une application beaucoup plus spécifique, par exemple dans le cas des modems, qui ouvrirait le premier modem disponible plutot que celui dont le client passe le nom si celui-ci est déjà occupé.

Les handles de fichiers renvoyés par rdeviced doivent être considérés par le client comme des handles distants, donc le client ne peut pas utiliser les fonctions génériques sur ces handles, il doit utiliser uniquement les fonctions de la librairie rdevice. En cas d'erreur, la variable errno du client est positionnée à la valeur de la variable errno du serveur. Les codes de retour renvoyés par le serveur sont ceux renvoyés par les fonctions standard utilisées en local. Dans le futur, le serveur ne devra pas retourner de vrais handles mais des handles internes ce qui permettra de stocker des informations pour chaque handle utilisé et d'être à accès concurrent.

Pour l'instant aucun contrôle n'est effectué pour tester la validité des paramètres, notamment des handles, transmis par le client.

Enfin, comme le serveur rdeviced est écrit symétriquement à la librairie cliente, on va décrire seulement les fonctions de la librairie.


Page précédente Page suivante Table des matières