1. Windows NT/2000/XP Enjeux et contraintes techniques Sixième partie COM – Notions avancées C. Casteyde Document diffusé sous licence GNU FDL

2. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

3. Multithreading et OLE ● Les nouveaux objets COM peuvent être multithreadés (Windows NT) ● Les anciens objets OLE ne supportent pas d'appels concurrents (Windows 3.1) ● Ils sont conçus pour fonctionner dans le thread principal (thread de la boucle de messages) ● Nécessité de la compatibilité ascendante ● Une technique d'isolation doit être développée

4. Notion d'appartement ● Contexte d'exécution des objets COM ● Chaque objet appartient à un appartement et un seul, et il ne « déménage » jamais ● Un appartement peut être mono ou multithreadé ● Chaque thread indique son modèle de threading via CoInitializeEx : – soit il est seul dans son appartement, – soit il est dans l'appartement multithreadé du processus.

5. Notion d'appartement ● Les appels entre deux appartements sont marshallés ● Ils sont exécutés sur l'un des threads de l'appartement ● Les appels sont sérialisés pour les objets des appartements mono threadés ● Il n'y a qu'un appartement multithreadé dans un processus

6. Appels sortant Appartement A Client Appel sortant Reprise d'exécution Attente active (boucle de messages) Appartement B Objet serveur Thread de traitement Exécution Requête Réponse

7. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

8. Création in-process ● Les objets COM des processus sont placés dans l'appartement du thread qui les crée ● Les objets des serveurs in-process sont créés : – dans un appartement qui leur convient, – choisi en fonction d'un « modèle de threading » défini en base de registres. ● Le premier thread « appartment threaded » du processus crée l'appartement principal (OLE)

9. Création in-process CO M Base de registres Localisation Modèle de threading CLSID CoCreateInstance Appartement B Objet serveur DLL Appartement A Objet serveur DLL Client Proxy/Stub

10. Modèles de threading in-process ● Il existe cinq modèles de thread pour les serveurs COM in- process : – mono threadé (objets OLE classiques), – apartment threaded (objets mono threadés), – free threaded (objets multi threadés purs), – both threaded (objets simples), – neutre (changements de contexte limités). ● Spécifié par la clef « ThreadingModel » en base de registres

11. Modèle monothreadé ● Utilisé pour les objets sans clef ThreadingModel ● Mode de compatibilité pour les anciens objets ● Utilise le premier appartement monothreadé de l'application ● Création de l'appartement si nécessaire (fortement déconseillé) ● Le thread de l'appartement doit exécuter une boucle de messages

12. Modèle apartment threaded ● ThreadingModel = 'Apartment' ● Les objets sont placés dans un appartement mono threadé ● Création de l'appartement si nécessaire ● Pas nécessairement l'appartement principal ● Nécessaire pour les contrôles ActiveX ● Le thread de l'appartement doit exécuter une boucle de messages

13. Modèle free threaded ● ThreadingModel = 'Free' ● Les objets sont placés dans l'appartement multithreadé ● Création de l'appartement si nécessaire ● Les objets doivent être thread-safe ● Pas de boucle de messages nécessaire ● Utilisation d'un pool de thread OLE pour les appels entrants

14. Modèle both threaded ● ThreadingModel = 'Both' ● Les objets sont placés dans l'appartement du thread créateur ● Pas de création d'appartement à la volée ● Les objets doivent être thread-safe ● Les objets doivent être réentrants ● Pas de callback asynchrones

15. Modèle neutre ● ThreadingModel = 'Neutral' ● Les objets sont placés dans l'appartement neutre (unique par processus, sans thread associé) ● Tous les appels sont directs (pas de changement de contexte) ● Marshalling systématique mais simplifié (pour les appels sortants) ● Même contraintes que les objets both threaded

16. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

17. Sécurité DCOM ● Paramétrable globalement ou au niveau de chaque composant dans DCOMCnfg ● Comprend les droits d'exécution des serveurs et d'autorisation d'accès ● Plusieurs niveaux d'authentification sont possibles ● Les serveurs peuvent définir leur propre politique d'accès (CoInitializeSecurity) ● Depuis XP SP2, des limites globales sont définies

18. DCOMCnfg

19. Utilisateurs COM/DCOM ● Les utilisateurs particuliers sont : – le « système » (obligatoire), – l'utilisateur « interactif » (requiert une session ouverte), – l'utilisateur « anonyme » (utilisateur des systèmes distants authentifiés), – « tout le monde ». ● En dehors d'un domaine : – comptes avec mot de passe identiques et non vides, – utilisateurs systèmes sont invités ou anonymes selon la stratégie de sécurité locale utilisée.

20. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

21. Comptes de références ● La durée de vie des objets est contrôlée par comptes de références ● Ne prend pas en compte les mécanismes de connexion applicatifs ● En réseau, l'applicatif doit surveiller ses clients ● Une erreur de compte peut être catastrophique : – utilisation d'objets détruits (jardinage, crash ultérieur), – non libération d'objets (client fautif non connu).

22. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

23. Conventions d'appel ● Les conventions d'appel doivent être fixées : – la représentation des données doit être la même, – le passage des paramètres doit être fixé, – règles de passage de paramètres strictes, – allocation et libération de la mémoire via IMalloc. ● Rappel : les paramètres de sortie doivent être : – alloués par l'appelé, – libérés par l'appelant, – l'appelé ne doit pas modifier les paramètres d'entrée.

24. Gestion de la mémoire ● Le non respect des conventions d'appel est systématiquement catastrophique : – destruction multiple de blocs (jardinage), – non destruction de blocs (leaks), – destruction par les stubs après l'appel (méthode fautive inconnue). ● Les types de données sont complexes : – BSTR (chaînes « Pascal »), OLESTR (chaînes C), – VARIANT, SAFEARRAY (tableau VB).

25. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

26. Étreintes fatales ● Les objets free threaded : – ont leurs requêtes effectuées sur des threads de travail, – ne sont jamais réentrés sur le même thread, – mais peuvent être accédés par plusieurs threads. ● Les sections critiques sont nécessaires, mais : – peuvent provoquer des interblocages entre appartements, – doivent être relâchées dans les appels sortants.

27. Étreintes fatales Appartement A (multithreadé) Thread 1 Thread 2 Lock() p->f() Lock() 2 5 3 Appartement B P Client 1 4

28. Réentrances ● Lors d'un appel depuis un appartement monothreadé : – OLE crée une boucle de messages temporaire, – attend la réponse de l'appel, – peut traiter des appels entrants vers un objet de l'appartement. ● Les objets single, apartment, both et neutral threaded doivent donc être réentrants.

29. Réentrances Appartement A boucle de messages Objet variable d'instance V Méthode V = 2 if (V == 1) p->f(); V == 2 ! Réentrance 1 4 5 8 Appartement B Objet serveur Appartement C Client 2 3 7 6

30. Réentrances ● Les objets monothreadés doivent donc : – soit ne pas faire d'appel « sortant » de l'appartement, – soit avoir une machine à état complète, – soit travailler sur des variables locales. ● Les sections critiques sont inopérantes : – les réentrances sont effectuées sur le même thread, – au mieux, cela provoquerait un auto-bloquage.

31. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

32. Contrôle de la liaison ● Il n'est pas possible de fixer les timeouts réseau ● En cas de chute du serveur : – 30 à 40 secondes par appel (blocage des autres clients), – timeout non systématique (sur lien local). ● En cas de chute du client, 8 mn de latence ● Forçage de la destruction des ressources clients impossible (AddRef maintenu par DCOM) ● Nécessité de lancer un thread par canal de communication

33. Threads de communication Connexion Thread de notification Machine A Serveur Machine B Client 1 Abonnemen t Notification Machine C Client 1

34. Déploiement réseau ● Configuration du déploiement non centralisée ● Configuration difficile ● Gestion des droits difficile et non maîtrisable ● Architecture centralisée (serveur de domaine) ● Conflits avec DHCP (rétablissement des liaisons) ● Requiert une infrastructure réseau propre

35. Plan ● Multithreading et COM – Notion d'appartement – Modèles de threading ● Sécurité DCOM ● Les pièges – Les comptes de références – Les conventions d'appel – Interblocages et réentrances – Pertes de liaison réseau ● Conclusion

36. Les contraintes COM/DCOM ● COM/DCOM est technique et dangereux : – gestion des ressources difficile (ressources mémoire, comptes de références), – gestion du multithreading difficile, – très difficile à déboguer, – contrôle de la liaison réseau quasi impossible, – gestion de la sécurité difficile.

37. Conclusion ● COM est difficile à maîtriser en détail ● Requiert une expertise importante ● En réseau, cette technologie est inutilisable ● Le déploiement est rendu technique en raison des problèmes de sécurité ● Ces contraintes doivent être prises en compte dès la conception des applications