Ta strona została przetłumaczona przez Cloud Translation API.

Przesyłane multimedia

Funkcja przesyłania multimediów umożliwia interfejsowi Campaign Manager 360 API przechowywanie danych w chmurze i udostępnianie ich na serwerze. Dane, które można przesłać, to m.in. zdjęcia, filmy, pliki PDF, pliki ZIP i inne typy danych.

Przykłady podane w tym dokumencie pokazują wykorzystanie przesyłania multimediów w fikcyjnym interfejsie API Farm. Te same pojęcia dotyczą jednak interfejsu Campaign Managera 360 API.

Opcje przesyłania

Interfejs Campaign Manager 360 API umożliwia przesyłanie określonych typów danych binarnych lub multimediów. Konkretne cechy danych, które możesz przesłać, są określone na stronie referencyjnej w przypadku każdej metody obsługującej przesyłanie multimediów:

Maksymalny rozmiar przesyłanego pliku: maksymalna ilość danych, które można przechowywać w przypadku danej metody.
Akceptowane typy MIME multimediów: typy danych binarnych, które można przechowywać przy użyciu tej metody.

Możesz wysyłać prośby o przesłanie w jeden z tych sposobów: Określ metodę, której używasz, za pomocą parametru żądania uploadType.

Proste przesyłanie: uploadType=media. Do szybkiego przenoszenia mniejszych plików, np. o wielkości maksymalnie 5 MB.
Przesyłanie wieloczęściowe: uploadType=multipart. do szybkiego przenoszenia mniejszych plików i metadanych; przesyła plik wraz z opisującymi go metadanymi, a wszystko to w ramach jednego żądania.
Przesyłanie z możliwością wznowienia: uploadType=resumable. Niezawodne przesyłanie, zwłaszcza w przypadku większych plików. Ta metoda wykorzystuje żądanie inicjujące sesję, które może opcjonalnie zawierać metadane. Jest to dobra strategia w przypadku większości aplikacji, ponieważ sprawdza się również w przypadku mniejszych plików, a jedynym kosztem jest jedno dodatkowe żądanie HTTP na każde przesłanie.

Podczas przesyłania multimediów używasz specjalnego identyfikatora URI. Metody obsługujące przesyłanie multimediów mają 2 punkty końcowe URI:

Identyfikator URI /upload dla multimediów. Format punktu końcowego przesyłania to standardowy identyfikator URI zasobu z prefiksem „/upload”. Użyj tego identyfikatora URI, gdy i samodzielnie przenosić dane multimediów.
Przykład: POST /upload/farm/v1/animals
Standardowy identyfikator URI zasobu dla metadanych. Jeśli zasób zawiera jakiekolwiek są pola danych służące do przechowywania metadanych opisujących przesłane . Możesz go używać podczas tworzenia lub aktualizowania wartości metadanych.
Przykład:POST /farm/v1/animals

Proste przesyłanie

Najprostszą metodą przesłania pliku jest przesłanie prostego żądania. Ta opcja jest dobrym wyborem, jeśli:

Plik jest na tyle mały, że można go przesłać ponownie w całości, jeśli połączenie się nie powiedzie.
Brak metadanych do wysłania. Może się tak zdarzyć, jeśli planujesz wysłać metadane tego zasobu w osobnym żądaniu lub jeśli metadane nie są obsługiwane lub niedostępne.

Aby użyć prostego przesyłania, wyślij prośbę o POST lub PUT do identyfikator URI metody /upload i dodaj parametr zapytania uploadType=media. Na przykład:

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=media

Nagłówki HTTP, których należy użyć w prostym żądaniu przesyłania:

Content-Type Ustaw jeden z akceptowanych typów przesyłanych danych multimediów do przesyłania, określony w dokumentacji interfejsu API.
Content-Length Ustaw liczbę przesyłanych bajtów. Nie jest wymagane, jeśli używasz kodowania częściowego transferu danych.

Przykład: prosty przesyłanie

Ten przykład pokazuje, jak wykorzystać proste żądanie przesłania dla fikcyjny interfejs Farm API.

POST /upload/farm/v1/animals?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/jpeg
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

JPEG data

Jeśli żądanie zostanie zrealizowane, serwer zwróci kod stanu HTTP 200 OK i wszystkie metadane:

HTTP/1.1 200
Content-Type: application/json

{
  "name": "Llama"
}

Przesyłanie wieloczęściowe

Jeśli masz metadane, które chcesz wysłać razem z danymi do przesłania, możesz wysłać pojedyncze żądanie multipart/related. Jest to dobry wybór, jeśli dane, które wysyłasz, są na tyle małe, że można je ponownie przesłać w całości, jeśli połączenie się nie powiedzie.

Aby użyć przesyłania wieloczęściowego, wyślij żądanie POST lub PUT do identyfikatora URI metody /upload i dodaj parametr zapytania uploadType=multipart, na przykład:

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=multipart

Nagłówki HTTP najwyższego poziomu, których należy używać podczas przesyłania żądania przesyłania wieloczęściowego:

Content-Type Ustaw jako wieloczęściową/powiązaną i uwzględnij ciąg granicy, którego używasz do identyfikowania części żądania.
Content-Length Ustaw łączną liczbę bajtów w treści żądania. Część multimedialna żądania musi być mniejsza niż maksymalny rozmiar pliku określony dla tej metody.

Treść żądania ma format multipart/related [RFC2387] i zawiera dokładnie 2 części. Części są oznaczone ciągiem znaków granicy, a po nim końcowym – 2 łączniki.

Każda część żądania wieloczęściowego musi zawierać dodatkowy nagłówek Content-Type:

Część z metadanymi: musi być pierwsza, a Content-Type musi odpowiadać jednemu z obsługiwanych formatów metadanych.
Część dotycząca multimediów: musi być drugą częścią, a Content-Type musi pasować do jednego z obsługiwanych przez metodę typów MIME multimediów.

W dokumentacji interfejsu API znajdziesz listę obsługiwanych typów MIME multimediów i limity rozmiarów przesłanych plików dla każdej metody.

Uwaga: aby utworzyć lub zaktualizować tylko część metadanych bez przesyłania powiązanych danych, wyślij żądanie POST lub PUT do standardowego punktu końcowego zasobu:https://www.googleapis.com/farm/v1/animals

Przykład: przesyłanie wieloczęściowe

Przykład poniżej przedstawia żądanie przesyłania wieloczęściowego dla fikcyjnego interfejsu Farm API.

POST /upload/farm/v1/animals?uploadType=multipart HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=foo_bar_baz
Content-Length: number_of_bytes_in_entire_request_body

--foo_bar_baz
Content-Type: application/json; charset=UTF-8

{
  "name": "Llama"
}

--foo_bar_baz
Content-Type: image/jpeg

JPEG data
--foo_bar_baz--

Jeśli żądanie zakończy się powodzeniem, serwer zwróci kod stanu HTTP 200 OK wraz z metadanymi:

HTTP/1.1 200
Content-Type: application/json

{
  "name": "Llama"
}

Przesyłanie z możliwością wznowienia

Aby zwiększyć niezawodność przesyłania plików danych, możesz użyć protokołu przesyłania z możliwością wznawiania. Ten protokół umożliwia wznowienie przesyłania po przerwaniu przepływu danych z powodu błędu komunikacji. Jest to szczególnie przydatne, gdy przesyłasz duże pliki i istnieje duże prawdopodobieństwo przerwania połączenia lub innego błędu transmisji, na przykład podczas przesyłania z aplikacji mobilnej. Może to również zmniejszyć wykorzystanie przepustowości w przypadku awarii sieci, ponieważ nie musisz ponownie rozpoczynać przesyłania dużych plików od początku.

Aby skorzystać z funkcji przesyłania z możliwością wznowienia:

Rozpocznij sesję, którą można wznowić. Prześlij pierwsze żądanie do identyfikatora URI przesyłania, który zawiera metadane (jeśli istnieją).
Zapisz identyfikator URI sesji do wznawiania. zapisz identyfikator URI sesji zwrócony w odpowiedzi na wstępne żądanie; Użyjesz go w pozostałych żądaniach w tej sesji.
Prześlij plik. Prześlij plik multimedialny do identyfikatora URI sesji z możliwością wznowienia.

Aplikacje korzystające z przesyłania możliwego do wznowienia muszą też zawierać kod umożliwiający wznowienie przerwanego przesyłania. Jeśli przesyłanie zostało przerwane, sprawdź, ile danych udało się odebrać, i wznów przesyłanie, zaczynając od tego momentu.

Uwaga: identyfikator URI przesyłania wygasa po tygodniu.

Krok 1. Rozpocznij sesję z możliwością wznowienia

Aby rozpocząć przesyłanie, które można wznowić, wyślij żądanie POST lub PUT do identyfikatora URI metody /upload i dodaj parametr zapytania uploadType=resumable, na przykład:

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable

W przypadku tego żądania inicjującego treść jest pusta lub zawiera tylko metadane. W kolejnych żądaniach przenosisz rzeczywiste dane pliku, który chcesz przesłać.

Użyj tych nagłówków HTTP w pierwszym żądaniu:

X-Upload-Content-Type. Ustaw typ MIME danych do przesłania, które mają być przesyłane w kolejnych żądaniach.
X-Upload-Content-Length. Ustaw liczbę bajtów danych do przesłania, które mają być przesyłane w kolejnych żądaniach. Jeśli długość jest nieznana w momencie wysyłania żądania, możesz pominąć ten nagłówek.
W przypadku dostarczania metadanych: Content-Type. Ustaw zgodnie z typem danych metadanych.
Content-Length Ustaw liczbę bajtów podanych w treści tego początkowego żądania. Nie jest wymagane, jeśli używasz kodowania transferu w porcjach.

Listę akceptowanych typów MIME multimediów i limitów rozmiarów przesyłanych plików znajdziesz w dokumentacji API.

Przykład: żądanie zainicjowania sesji z możliwością wznowienia

Ten przykład pokazuje, jak zainicjować sesję z możliwością wznowienia w przypadku fikcyjnego interfejsu Farm API.

POST /upload/farm/v1/animals?uploadType=resumable HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Type: image/jpeg
X-Upload-Content-Length: 2000000

{
  "name": "Llama"
}

Uwaga: w przypadku początkowego, możliwego do wznowienia żądania aktualizacji bez metadanych pozostaw treść żądania pustą i ustaw nagłówek Content-Length na 0.

W następnej sekcji znajdziesz informacje o tym, jak postępować w przypadku otrzymania takiej odpowiedzi.

Krok 2. Zapisz identyfikator URI sesji, którą można wznowić

Jeśli żądanie zainicjowania sesji zostanie zrealizowane, serwer interfejsu API w odpowiedzi przesyła kod stanu HTTP 200 OK. Dodatkowo zawiera nagłówek Location, który określa identyfikator URI sesji z możliwością wznowienia. Nagłówek Location, pokazany w przykładzie poniżej, zawiera część parametru zapytania upload_id, która zawiera unikalny identyfikator przesyłania do użycia w tej sesji.

Przykład: odpowiedź na inicjowanie sesji z możliwością wznowienia

Oto odpowiedź na żądanie z kroku 1:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

Wartość nagłówka Location, jak pokazano w przykładowej powyżej odpowiedzi, to identyfikator URI sesji, którego użyjesz jako punktu końcowego HTTP, by przesłać plik lub wysłać zapytanie o stan przesyłania.

Skopiuj i zapisz identyfikator URI sesji, by móc go używać w kolejnych żądaniach.

Krok 3: prześlij plik

Aby przesłać plik, wyślij żądanie PUT pod identyfikator URI przesyłania uzyskany w poprzednim kroku. Prośba o przesłanie pliku jest w formacie:

PUT session_uri

Nagłówki HTTP, których należy używać podczas przesyłania żądań przesyłania plików z możliwością wznowienia, obejmują Content-Length. Ustaw tę wartość na liczbę bajtów, które chcesz przesłać w ramach tego żądania. Jest to zwykle rozmiar przesyłanego pliku.

Przykład: żądanie wznowienia przesłania pliku

Oto przykładowa prośba o przesłanie całego pliku JPEG o rozmiarach 2 000 000 bajtów, którą można wznowić.

PUT https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: image/jpeg

bytes 0-1999999

Jeśli żądanie zostało wykonane, serwer odpowiada HTTP 201 Created wraz z metadanymi powiązanymi z tym zasobem. Jeśli początkowe żądanie sesji z możliwością wznowienia było PUT, aby zaktualizować istniejący zasób, odpowiedź na żądanie będzie 200 OK wraz z metadanymi powiązanymi z tym zasobem.

Jeśli żądanie przesyłania zostanie przerwane lub otrzymasz z serwera odpowiedź HTTP 503 Service Unavailable albo inną 5xx, postępuj zgodnie z procedurą opisaną w artykule Wznawianie przerwanego przesyłania.

Przesyłanie pliku w kawałkach

Dzięki wznawianiu przesyłania możesz podzielić plik na fragmenty i wysłać serię żądań, aby przesłać każdy fragment po kolei. Nie jest to preferowane podejście, ponieważ dodatkowe żądania wiążą się z kosztami wydajności, więc zasadniczo nie jest to potrzebne. Aby jednak ograniczyć ilość danych przesyłanych w jednym żądaniu, może być konieczne użycie dzielenia na fragmenty. Jest to przydatne, gdy istnieje stały limit czasowy dla poszczególnych żądań, tak jak w przypadku niektórych klas żądań Google App Engine. Umożliwia też wyświetlanie informacji o postępie przesyłania w starszych przeglądarkach, które nie obsługują domyślnie postępu przesyłania.

Rozwiń, aby wyświetlić więcej informacji

Jeśli przesyłasz dane we fragmentach, wymagany jest też nagłówek Content-Range oraz nagłówek Content-Length wymagany przy przesyłaniu pełnych plików:

Content-Length Ustaw rozmiar fragmentu lub być może mniejszy, jak w przypadku ostatniego żądania.
Content-Range: pokazuje, jakie bajty w przesyłanym pliku są widoczne. Na przykład Content-Range: bytes 0-524287/2000000 oznacza, że przesyłasz pierwsze 524 288 bajtów (256 x 1024 x 2) z pliku o rozmiarze 2 000 000 bajtów.

Ograniczenie rozmiaru fragmentu: wszystkie fragmenty muszą być wielokrotnością rozmiaru 256 KB (256 x 1024 bajty), z wyjątkiem ostatniego fragmentu, który kończy przesyłanie. Jeśli chcesz dzielić na fragmenty, zadbaj o to, aby rozmiar był jak największy, aby przesyłanie przebiegało wydajnie.

Przykład: żądanie wznowienia przesyłania podzielonego pliku

Żądanie, które wysyła pierwsze 524 288 bajtów, może wyglądać tak:

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: image/jpeg
Content-Range: bytes 0-524287/2000000

bytes 0-524288

Jeśli żądanie zostanie zrealizowane, serwer odpowie 308 Resume Incomplete wraz z nagłówkiem Range, który identyfikuje łączną liczbę bajtów, które zostały do tej pory zapisane:

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: bytes=0-524287

Aby określić, gdzie ma się rozpocząć kolejny fragment, użyj większej wartości zwróconej w nagłówku Range. Kontynuuj PUT każdego fragmentu pliku, aż zostanie przesłany cały plik.

Jeśli żądanie PUT dowolnego fragmentu zostanie przerwane lub jeśli serwer zwróci kod stanu HTTP 503 Service Unavailable lub dowolny inny kod stanu 5xx, postępuj zgodnie z instrukcjami opisanymi w sekcji Wznawianie przerwanego przesyłania, ale zamiast przesyłać resztę pliku, po prostu kontynuuj przesyłanie fragmentów od tego miejsca.

Ważne uwagi:

Pamiętaj o użyciu nagłówka Range w odpowiedzi, aby określić miejsce rozpoczęcia następnego fragmentu. nie zakładaj, że serwer otrzymał wszystkie bajty wysłane w poprzednim żądaniu.
Każdy URI przesyłania ma ograniczony czas ważności i ostatecznie wygasa (w ciągu około doby, jeśli nie zostanie użyty). Z tego powodu najlepiej jest rozpocząć wznawianie przesyłania zaraz po uzyskaniu identyfikatora URI przesyłania i wznowić przerwane przesyłanie wkrótce po przerwie.
Jeśli wyślesz żądanie z identyfikatorem sesji przesyłania, który wygasł, serwer zwróci kod stanu 404 Not Found. Gdy w sesji przesyłania wystąpi nieodwracalny błąd, serwer zwraca kod stanu 410 Gone. W takich przypadkach musisz rozpocząć nowe przesyłanie z możliwością wznowienia, uzyskać nowy identyfikator URI przesyłania i zacząć przesyłanie od początku, korzystając z nowego punktu końcowego.

Gdy przesłanie całego pliku zostanie zakończone, serwer odpowie, zwracając HTTP 201 Created wraz z metadanymi powiązanymi z tym zasobem. Gdyby to żądanie miało na celu zaktualizowanie istniejącego elementu zamiast utworzenia nowego, kod odpowiedzi HTTP po zakończeniu przesyłania byłby 200 OK.

Wznawianie przerwanego przesyłania

Jeśli żądanie przesyłania zostanie zakończone przed otrzymaniem odpowiedzi lub w przypadku otrzymania z serwera odpowiedzi HTTP 503 Service Unavailable, musisz wznowić przerwane przesyłanie. Aby to zrobić:

Stan żądania. Aby sprawdzić bieżący stan przesyłania, wyślij puste żądanie PUT do identyfikatora URI przesyłania. W przypadku tego żądania nagłówki HTTP powinny zawierać nagłówek Content-Range wskazujący, że bieżąca pozycja w pliku jest nieznana. Jeśli np. łączna długość pliku wynosi 2 000 000, ustaw Content-Range na */2000000. Jeśli nie znasz pełnego rozmiaru pliku, ustaw Content-Range na */*.
Uwaga: możesz sprawdzać stan poszczególnych fragmentów nie tylko w przypadku przerwania przesyłania. Jest to przydatne na przykład wtedy, gdy chcesz wyświetlać informacje o postępie przesyłania w starszych przeglądarkach.
Sprawdź liczbę przesłanych bajtów. Przetworzenie odpowiedzi na zapytanie o stan. Serwer używa w odpowiedzi nagłówka Range, aby określić, które bajty odebrał do tej pory. Na przykład nagłówek Range o wartości 0-299999 oznacza, że otrzymano pierwsze 300 000 bajtów pliku.
Prześlij pozostałe dane. Wiesz już, gdzie wznowić żądanie, możesz wysłać pozostałe dane lub bieżący fragment. Pamiętaj, że w każdym przypadku pozostałe dane musisz traktować jako oddzielny fragment, więc po wznowieniu przesyłania musisz wysłać nagłówek Content-Range.

Przykład: wznawianie przerwanego przesyłania

1) Poproś o stan przesyłania.

To żądanie używa nagłówka Content-Range,aby wskazać,że bieżąca pozycja pliku o wielkości 2 000 000 bajtów jest nieznana.

PUT {session_uri} HTTP/1.1
Content-Length: 0
Content-Range: bytes */2000000

2) Pobierz z odpowiedzi liczbę przesłanych do tej pory bajtów.

Odpowiedź serwera wykorzystuje nagłówek Range, aby wskazać, że odebrał do tej pory pierwsze 43 bajty pliku. Użyj górnej wartości nagłówka Range, aby określić, gdzie rozpocząć wznowione przesyłanie.

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42

Uwaga: jeśli przesyłanie zostało zakończone, odpowiedź dotycząca stanu może brzmieć 201 Created lub 200 OK. Może się tak zdarzyć, jeśli połączenie zostanie zerwane po przesłaniu wszystkich bajtów, ale zanim klient otrzyma odpowiedź od serwera.

3) Wznów przesyłanie od miejsca, w którym zostało przerwane.

Kolejne żądanie wznowi przesyłanie, wysyłając pozostałe bajty pliku, zaczynając od bajtu 43.

PUT {session_uri} HTTP/1.1
Content-Length: 1999957
Content-Range: bytes 43-1999999/2000000

bytes 43-1999999

Sprawdzone metody

Podczas przesyłania multimediów warto pamiętać o kilku sprawdzonych metodach dotyczących obsługi błędów.

Wznów lub ponów przesyłanie, które nie powiodły się z powodu przerw w połączeniu lub błędów 5xx, w tym:
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
Jeśli podczas wznawiania lub ponawiania żądań przesyłania wystąpi dowolny błąd serwera 5xx, użyj strategii wykładniczego ponowienia. Te błędy mogą wystąpić, jeśli serwer jest przeciążony. Wykładniczy czas do ponowienia może pomóc złagodzić tego typu problemy w okresach dużej liczby żądań lub dużego ruchu w sieci.
Inne rodzaje żądań nie powinny być obsługiwane przez wykładniczy czas do ponowienia, ale nadal możesz ponawiać kilka prób. Gdy powtarzasz te żądania, ogranicz liczbę prób. Na przykład Twój kod może ograniczyć liczbę prób do 10 lub mniej, zanim zgłosi błąd.
Rozwiązywanie błędów 404 Not Found i 410 Gone podczas przesyłania z możliwością wznowienia, przez ponowne rozpoczęcie całego przesyłania od początku.

Wykładniczy czas do ponowienia

Wykładniczy czas ponowienia to standardowa strategia obsługi błędów w aplikacjach sieciowych, w których klient okresowo ponawia nieudane żądanie w coraz większym czasie. Jeśli z powodu dużej liczby żądań lub dużego ruchu sieciowego serwer zwraca błędy, dobrym rozwiązaniem będzie stosowanie wzrastającego czasu do ponowienia. Nie jest to jednak odpowiednia strategia na radzenie sobie z błędami niezwiązanymi z objętością sieci lub czasem odpowiedzi, np. z błędami nieprawidłowych danych autoryzujących lub nie znaleziono pliku.

Prawidłowo używany, rosnący wykładniczy czas ponowienia zwiększa wydajność wykorzystania przepustowości, zmniejsza liczbę żądań wymaganych do uzyskania pomyślnej odpowiedzi i maksymalizuje przepustowość żądań w środowiskach równoczesnych.

Proces implementacji prostego wzrastającego czasu do ponowienia jest następujący:

Wyślij żądanie do interfejsu API.
Otrzymasz odpowiedź HTTP 503, która oznacza, że należy ponowić żądanie.
Odczekaj 1 sekundę + los_number_milliseconds i spróbuj ponownie.
Otrzymasz odpowiedź HTTP 503, która oznacza, że należy ponowić żądanie.
Zaczekaj 2 sekundy + random_number_milliseconds i ponownie prześlij żądanie.
Otrzymasz odpowiedź HTTP 503, która oznacza, że należy ponowić żądanie.
Odczekaj 4 sekundy + random_number_milliseconds i spróbuj ponownie.
Otrzymasz odpowiedź HTTP 503, która wskazuje, że należy ponownie wysłać żądanie.
Odczekaj 8 sekund + los_number_milliseconds i spróbuj ponownie.
Otrzymasz odpowiedź HTTP 503, która oznacza, że należy ponowić żądanie.
Zaczekaj 16 sekund + random_number_milliseconds i ponownie prześlij żądanie.
Zatrzymaj. Zgłoś lub zapisz błąd.

W tym przykładzie losowo_liczba_milisekund to losowa liczba milisekund mniejsza lub równa 1000. Jest to konieczne, ponieważ wprowadzenie niewielkiego losowego opóźnienia pomaga bardziej równomiernie rozłożyć obciążenie i uniknąć możliwości przytłoczenia serwera. Po każdym oczekiwaniu należy ponownie zdefiniować wartość parametru random_number_milliseconds.

Uwaga: czas oczekiwania to zawsze (2 ^ n) + random_number_milliseconds, gdzie n to monotonicznie rosnąca liczba całkowita zdefiniowana początkowo jako 0. Liczba całkowita n zwiększa się o 1 dla każdej iteracji (każdego żądania).

Algorytm jest ustawiony tak, aby zakończyć działanie, gdy n = 5. Taki limit uniemożliwia klientom ponawianie prób w nieskończoność i powoduje, że żądanie zostaje uznane za „błąd nieodwracalny” wynoszący około 32 sekundy. Większa maksymalna liczba ponownych prób to dobre rozwiązanie, zwłaszcza w przypadku długiego przesyłania. pamiętaj, aby ograniczyć opóźnienie ponawiania do rozsądnej, na przykład niecałej minuty.