LPM_AdmitRsvpMsg, fonction (lpmapi.h)
La fonction LPM_AdmitRsvpMsg est appelée par le PCM pour transmettre des messages RSVP au LPM pour les décisions de contrôle d’admission basées sur des stratégies. Les résultats de l’appel de LPM_AdmitRsvpMsg peuvent être repassé au PCM de manière synchrone ou asynchrone en définissant la valeur de retour de manière appropriée. Les résultats asynchrones doivent être retournés en appelant la fonction cbAdmitResult .
Syntaxe
ULONG LPM_AdmitRsvpMsg(
[in] RHANDLE PcmReqHandle,
[in] RSVP_HOP *pRecvdIntf,
[in] RSVP_MSG_OBJS *pRsvpMsgObjs,
[in] int RcvdRsvpMsgLength,
[in] UCHAR *RcvdRsvpMsg,
[out] ULONG *pulPcmActionFlags,
[out] POLICY_DECISION *pPolicyDecisions,
[out] void *Reserved
);
Paramètres
[in] PcmReqHandle
Handle unique qui identifie cette demande à partir de toutes les autres demandes. Les LPM doivent passer ce handle au PCM lors du retour asynchrone des résultats pour une requête individuelle en appelant cbAdmitResult. Le paramètre PcmReqHandle devient non valide une fois les résultats retournés, ce qui oblige chaque requête à obtenir son propre PcmReqHandle unique à partir du PCM.
[in] pRecvdIntf
Pointeur vers l’interface sur laquelle le message a été reçu. L’adresse IP de l’interface reçue est fournie en tant qu’objet RSVP HOP et le handle d’interface logique est défini sur l’index SNMP. Notez que les numéros d’index d’interface peuvent changer avec l’ajout et la suppression d’interfaces, en raison des fonctionnalités Plug-and-Play de Windows 2000.
[in] pRsvpMsgObjs
Objets reçus de RSVP. Le SBM décompresse les messages RSVP reçus en objets individuels et convertit le contenu de ces objets RSVP dans l’ordre de l’hôte et les fournit dans la structure RSVP_MSG_OBJS , qui est définie dans Lpmapi.h. Les objets suivants sont fournis.
[in] RcvdRsvpMsgLength
Longueur du message RSVP reçu, en octets.
[in] RcvdRsvpMsg
Message RSVP, dans l’ordre réseau.
[out] pulPcmActionFlags
Indicateurs utilisés pour spécifier une action demandée du PCM. Le LPM peut actuellement définir ce paramètre sur FORCE_IMMEDIATE_REFRESH pour demander une actualisation immédiate du message admis. Un LPM peut définir cet indicateur si une modification des données de stratégie qu’elle souhaite transférer immédiatement est détectée. Avant l’envoi, le SBM demande au LPM de fournir des informations de stratégie pour le message d’actualisation sortant.
Notez que les LPM n’ont pas besoin de définir cet indicateur lorsqu’un nouveau message PATH est accepté ; Les SBC envoient automatiquement le nouveau message PATH aux récepteurs.
[out] pPolicyDecisions
Pointeur vers les décisions de stratégie. Un LPM doit allouer cette mémoire tampon à l’aide de l’allocateur de mémoire fourni dans l’appel de fonction LPM_Initialize ; le SBM libère la mémoire tampon après avoir agi sur pPolicyDecisions. Le PCM examine pPolicyDecisions uniquement lorsque la fonction retourne LPM_RESULT_READY. Les décisions de stratégie synchrone doivent être retournées pour chaque flux dans FlowDescList, et le nombre d’entrées dans le tableau pPolicyDecisions doit être égal à FlowDescListCount. Chaque décision de stratégie se compose des valeurs indiquées dans le tableau suivant.
Valeur | Signification |
---|---|
|
Pointeur vers une mémoire tampon pour recevoir la valeur de priorité LPM du LPM. Notez que le PCM examine ce paramètre uniquement si la valeur de retour de LPM_AdmitRsvpMsg est définie sur LPM_RESULT_READY. Si le LPM retourne des résultats de manière synchrone, ce paramètre doit être défini sur une valeur de priorité valide. Pour plus d’informations, consultez Module de stratégie locale . |
|
Pointeur vers un code d’erreur de stratégie. Si la demande est rejetée de manière synchrone, les LPM doivent fournir une valeur différente de zéro pour ce paramètre ; Le SBM copie cette valeur, en combinaison avec PolicyErrorValue, dans l’objet d’erreur RSVP lors de l’envoi de messages PATHERR ou RESVERR (suite à l’échec du contrôle d’admission basé sur une stratégie, pour fournir une raison de rejeter la demande). |
|
Pointeur vers une valeur d’erreur de stratégie. Si la demande est rejetée de manière synchrone, les LPM doivent fournir une valeur différente de zéro pour ce paramètre ; Le SBM copie cette valeur, en combinaison avec PolicyErrorCode, dans l’objet d’erreur RSVP lors de l’envoi de messages PATHERR ou RESVERR (en raison d’un échec du contrôle d’admission basé sur une stratégie, pour fournir une raison de rejeter la demande). |
Étant donné que l’POLICY_DECISION de retour d’un LPM est un tableau, un LPM peut accepter un sous-ensemble de flux dans FlowDescList et rejeter le reste d’entre eux, le cas échéant. Par exemple, étant donné que les messages RESV de style FF peuvent contenir plusieurs flux, lorsqu’un LPM rejette certains flux et en accepte d’autres, le SBM génère un message RESVERR distinct pour chaque flux rejeté ; avant d’envoyer le message RESVERR, PCM appelle chaque LPM pour fournir des objets de données de stratégie pour chaque message RESVERR sortant.
[out] Reserved
Réservé pour un usage futur.
Valeur retournée
Cette fonction retourne ULONG.
Remarques
Le gestionnaire de bande passante de sous-réseau (SBM) transfère les messages RSVP PATH, RESV, PATHERR, RESVERR, PATH_TEAR et RESV_TEAR au PCM. Si une demande transmet l’admission basée sur la stratégie LPM (auquel cas le status de réussite est transmis via le PCM au SBM), le SBM effectue le contrôle d’admission basé sur les ressources dans le cadre de son traitement RSVP ; si le contrôle d’admission basé sur les ressources échoue, le SBM demande au PCM de demander à chaque LPM de supprimer son état par le biais de la fonction LPM_CommitResv. Dans de telles circonstances, le SBM (et non les LPM) crée le message d’erreur RSVP requis.
Configuration requise
Condition requise | Valeur |
---|---|
Client minimal pris en charge | Windows 2000 Professionnel [applications de bureau uniquement] |
Serveur minimal pris en charge | Windows 2000 Server [applications de bureau uniquement] |
Plateforme cible | Windows |
En-tête | lpmapi.h |
Voir aussi
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour