Freigeben über


Verhindern mehrerer Uploads

Wenn Sie eine Datei hochladen, erstellt BITS eine Sitzungs-ID, die die Uploadsitzung sowohl auf den BITS-Client als auch auf den BITS-Server identifiziert. Wenn die Verbindung zwischen dem BITS-Client und dem Server unterbrochen wird, während BITS eine Datei hochlädt, verwendet der Client die Sitzungs-ID, um den Upload fortzusetzen.

Wenn der BITS-Client eine Verbindung mit demselben Server wie zuvor herstellt, erkennt der Server die Sitzungs-ID, und der Upload wird ab dem Zeitpunkt der Unterbrechung fortgesetzt. Wenn der Client jedoch eine Verbindung mit einem anderen Server herstellt, muss der Client den Upload von Anfang an starten, da der neue Server nicht über den Sitzungskontext oder die zuvor hochgeladenen Daten verfügt. BITS kann eine Verbindung mit einem anderen Server herstellen, wenn der BITS-Server in einer Webfarm gehostet wird und die BITS-IIS-Erweiterungseigenschaft BITSHostId nicht festgelegt ist. Die BITSHostId-Eigenschaft verhindert Neustarts, indem der BITS-Client gezwungen wird, eine Verbindung mit der eindeutigen Adresse des vorherigen Servers anstelle der freigegebenen Serveradresse herzustellen.

Der BITS-Server versucht, die Uploaddatei nur einmal an die Serveranwendung zu senden, aber es ist möglich, dass die Datei mehrmals gesendet wird. Dies kann beispielsweise der Fall sein, wenn der BITS-Server die Datei an die Serveranwendung sendet und dann beendet wird, während er auf die Antwort von der Serveranwendung wartet. Der BITS-Client empfängt einen Fehlercode von der HTTP-Ebene und wiederholt den Upload nach einer Verzögerung. Wenn der Server länger als das BITSHostIdFallbackTimeout-Timeout offline bleibt, sendet der Client die Anforderung schließlich erneut an die Adresse des freigegebenen Servers. Ein anderer BITS-Server empfängt die Datei und übermittelt sie erneut an die Serveranwendung.

Ein ähnlicher Fall kann auch bei einem einzelnen Front-End-Server auftreten. Wenn der Client beispielsweise die gesamte Datei auf den Server hochgeladen hat, bewirkt der letzte Block, dass der Server die Datei an die Serveranwendung weiterleitet. Wenn der BITS-Server oder die Serveranwendung beendet wird, nachdem die Datei verarbeitet wurde, aber bevor die Bestätigung an den Client gesendet wird, erhält der Client einen Fehlercode und versucht es später erneut. Wenn der Client erneut versucht, erkennt der BITS-Server, dass der endgültige Block hochgeladen wurde, und leitet die Datei erneut an die Serveranwendung weiter. Wenn das mehrfache Empfangen der Uploaddatei ein Problem für Ihre Serveranwendung ist, sollten Sie erwägen, einen Transaktionsbezeichner in die Daten einzubeigen.