Prévention des chargements multiples

Lorsque vous chargez un fichier, BITS crée un ID de session qui identifie la session de chargement sur le client BITS et le serveur BITS. Si la connexion entre le client BITS et le serveur est interrompue pendant le chargement d’un fichier, le client utilise l’ID de session pour essayer de reprendre le chargement.

Si le client BITS se connecte au même serveur que précédemment, le serveur reconnaît l’ID de session et le chargement reprend à partir du point d’interruption. Toutefois, si le client se connecte à un autre serveur, le client doit démarrer le chargement à partir du début, car le nouveau serveur n’a pas le contexte de session ni les données précédemment chargées. BITS peut se connecter à un autre serveur lorsque le serveur BITS est hébergé sur une batterie de serveurs web et que la propriété d’extension BITS IIS, BITSHostId, n’est pas définie. La propriété BITSHostId empêche les redémarrages en forçant le client BITS à se connecter à l’adresse unique du serveur précédent au lieu de l’adresse du serveur partagé.

Le serveur BITS tente d’envoyer le fichier de chargement une seule fois à l’application serveur, mais il est possible que le fichier soit envoyé plusieurs fois. Cela peut se produire, par exemple, si le serveur BITS envoie le fichier à l’application serveur, puis se termine en attendant la réponse de l’application serveur. Le client BITS reçoit un code d’erreur de la couche HTTP et réessaye le chargement après un délai. Si le serveur reste hors connexion plus longtemps que le BITSHostIdFallbackTimeout délai d’expiration, le client envoie à nouveau la demande à l’adresse du serveur partagé ; Un autre serveur BITS reçoit le fichier et le remet à nouveau à l’application serveur.

Un cas similaire peut se produire même avec un serveur frontal unique. Par exemple, lorsque le client a chargé l’intégralité du fichier sur le serveur, le bloc final entraîne le transfert du fichier vers l’application serveur. Si le serveur BITS ou l’application serveur se termine une fois le fichier traité, mais avant l’envoi de l’accusé de réception au client, le client reçoit un code d’erreur et réessaye ultérieurement. Lorsque le client retente, le serveur BITS voit que le bloc final a été chargé et qu’il transfère à nouveau le fichier à l’application serveur. Si la réception du fichier de chargement plusieurs fois est un problème pour votre application serveur, vous devez envisager d’inclure un identificateur de transaction dans les données.