Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 ist, 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 BITSHostIdnicht 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 z. B. auftreten, wenn der BITS-Server die Datei an die Serveranwendung sendet und dann beendet wird, während sie 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 offline bleibt als die BITSHostIdFallbackTimeout Timeout, sendet der Client die Anforderung schließlich erneut an die freigegebene Serveradresse; Ein anderer BITS-Server empfängt die Datei und liefert 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 nach dem Verarbeiten der Datei beendet werden, 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, wird dem BITS-Server angezeigt, dass der endgültige Block hochgeladen wurde, und er leitet die Datei erneut an die Serveranwendung weiter. Wenn der Empfang der Uploaddatei mehrmals ein Problem für Ihre Serveranwendung ist, sollten Sie erwägen, einen Transaktionsbezeichner in die Daten einzugeben.