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 que BITS charge 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 qu’auparavant, 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 téléchargement à partir du début, car le nouveau serveur n’a pas le contexte de session ou 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 IIS BITS, 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 pendant plus longtemps que le délai d’attente BITSHostIdFallbackTimeout , le client renvoie finalement 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 seul serveur frontal. Par exemple, lorsque le client a chargé l’intégralité du fichier sur le serveur, le dernier bloc oblige le serveur à transférer le fichier à l’application serveur. Si le serveur BITS ou l’application serveur se termine après le traitement du fichier, mais avant l’envoi de l’accusé de réception au client, le client recevra un code d’erreur et réessayera ultérieurement. Lorsque le client effectue une nouvelle tentative, le serveur BITS voit que le bloc final a été chargé et il transfère à nouveau le fichier vers 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.