Dlaczego w programowaniu internetowym akceptowane są ankiety?

108

Obecnie pracuję nad projektem Ruby on Rails , który pokazuje listę obrazów.

Niezbędnym elementem tego projektu jest to, że pokazuje on nowe posty w czasie rzeczywistym bez konieczności odświeżania strony internetowej. Po pewnym czasie natknąłem się na niektóre rozwiązania i usługi JavaScript, takie jak PubNub; jednak żadne z dostarczonych rozwiązań w ogóle nie miało sensu.

W rozwiązaniu JavaScript ( odpytywanie ) dzieje się:

Użytkownik 1 wyświetla listę zdjęć.
W tle kod JavaScript odpytuje punkt końcowy co sekundę, aby sprawdzić, czy jest nowy post.
Użytkownik 2 dodaje nowe zdjęcie.
Wystąpiło opóźnienie 50 ms przed uruchomieniem nowego cyklu i pobraniem nowych danych.
Nowa zawartość jest ładowana do DOM .

Wydaje się to dziwne w tłumaczeniu na przykład z prawdziwego świata:

Użytkownik 1 trzyma stos zdjęć na swoim biurku.
Co sekundę podchodzi do fotografa i pyta, czy ma nowego.
Fotograf robi nowe zdjęcie.
W tym momencie, gdy on / ona wchodzi, może zrobić zdjęcie i położyć je na stosie.

Moim zdaniem rozwiązanie powinno wyglądać następująco:

Użytkownik 1 trzyma stos zdjęć na swoim biurku.
Fotograf robi nowe zdjęcie.
Fotograf podchodzi do stosu i kładzie go z resztą.

Rozwiązanie PubNub jest w zasadzie takie samo, jednak tym razem między stronami chodzi stażysta, aby udostępnić dane.

Nie trzeba dodawać, że oba rozwiązania są bardzo energochłonne, ponieważ uruchamiane są nawet wtedy, gdy nie ma danych do załadowania.

O ile mi wiadomo, nie ma (logicznego) wyjaśnienia, dlaczego ten sposób implementacji jest stosowany w prawie każdej aplikacji w czasie rzeczywistym.

loops logic polling

— dennis
źródło

195

Ignorując przez chwilę, że przeglądarki nie są serwerami, które mogą odbierać połączenia przychodzące ... czekaj, nie, nie ignoruj tego.

— GrandmasterB

17

@dennis: stanowe, trwałe połączenie między serwerem a klientem prawdopodobnie pozbyłoby się potrzeby odpytywania, ale nie tak zaprojektowano sieć.

— FrustratedWithFormsDesigner

58

Co powiesz na Websockets?

— I.devries

25

Lub spójrz na długie ankiety. Zasadniczo odpytujesz, ale serwer nie odpowiada, zanim nie pojawi się w nim żadna nowa informacja.

— Matsemann

53

Istnieje wiele całkowicie sensownych rozwiązań i algorytmów w przestrzeni komputerowej, które w absurdzie byłyby całkowicie absurdalne.

— whatsisname

179

Pushing działa dobrze dla 1 lub ograniczonej liczby użytkowników.

Teraz zmień scenariusz z jednym fotografem i 1000 użytkowników, którzy chcą kopii tego zdjęcia. Fotograf będzie musiał przejść do 1000 stosów. Niektóre z nich mogą znajdować się w zamkniętym biurze lub rozrzucone po całej podłodze. Lub ich użytkownik na wakacjach i brak zainteresowania w tej chwili nowymi zdjęciami.

Fotograf byłby cały czas zajęty spacerowaniem i nie robiłby nowych zdjęć.

Zasadniczo: model ściągania / odpytywania lepiej skaluje się do wielu niewiarygodnych czytelników z luźnymi wymaganiami w czasie rzeczywistym (jeśli zdjęcie zajmie 10 sekund później, aby dotrzeć na stos, co jest wielka sprawa).

To powiedziawszy, model push jest wciąż lepszy w wielu sytuacjach. Jeśli potrzebujesz małego opóźnienia (potrzebujesz tego nowego zdjęcia po 5 sekundach) lub aktualizacje są rzadkie, a prośby są częste i przewidywalne (pytaj fotografa co 10 sekund, kiedy generuje nowe zdjęcie dziennie), wtedy ciągnięcie jest nieodpowiednie. To zależy od tego, co próbujesz zrobić. NASDAQ: push. Serwis pogodowy: ciągnij. Fotograf ślubny: prawdopodobnie pociągnij. News agencja fotograficzna: prawdopodobnie push.

— ptyx
źródło

32

Bardzo podoba mi się twoja analogia z 1000 użytkownikami, niektórzy na wakacjach, niektórzy niezainteresowani. +1.

— riwalk

4

@EsbenSkovPedersen: Limit gniazd nie wynika z adresu IP. Wynika to z maksymalnego otwartego deskryptora pliku. Zatem maksymalna liczba otwartych gniazd jest niezależna od liczby używanych adresów IP.

— slebetman

10

Jest to okropna analogia, delikatnie mówiąc. Aby push działał, każdy klient użytkownika musi utrzymywać pewnego rodzaju otwarte połączenie. W rzeczywistości odpytywanie jest emulacją połączenia. To nie jest tak, ponieważ niektórzy klienci sondują, że wszyscy klienci są powiadamiani. Podobnie, gdy niektórzy klienci otwierają połączenie dla powiadomień push, nie wszyscy klienci są powiadamiani. To bardzo słaba rada, która zachęca do wyrzucania zasobów przez okno. Bombardowanie 10000 żądaniami na sekundę praktycznie nigdy nie jest tańsze ani lepsze niż utrzymanie 10000 otwartych gniazd.

— back2dos

8

@ptyx: interwał 1s jest omawiany tutaj. 10 000 żądań na sekundę oznacza 10 000 uzgodnień TCP i 10 000 żądań HTTP (każde z łatwością osiąga 2 KB), co daje wiele rzędów wielkości więcej szumu tła uderzającego w twój serwer. Istnieje wiele bibliotek testowanych w bitwie, dzięki którym subskrypcje wypychane są tak proste, jak wprowadzenie odpytywania. Istnieją nawet frameworki takie jak meteor.js, które całkowicie odciągają cały problem. Odwoływanie się do skalowalności bez dalszych wyjaśnień również nie jest argumentem. W każdym razie

— wyraziłem

5

Zgadzam się z powyższym komentarzem back2dos. Gdyby pull był skalowany lepiej niż push, google, wymiana stosów, facebook, internetowe usługi giełdowe itp. Korzystałyby z technologii pull. Ale oni nie. Zasadniczo wbijanie serwera zamiast konfigurowania stacji nasłuchowej jest straszne. Główne usługi unikają odpytywania.

— Travis J

106

Jestem naprawdę zaskoczony, że tylko jedna osoba wspomniała o WebSockets . Wsparcie jest realizowane w zasadzie w każdej dużej przeglądarce .

W rzeczywistości PubNub ich używa. W przypadku Twojej aplikacji przeglądarka prawdopodobnie zasubskrybuje gniazdo, które będzie nadawać, gdy tylko będzie dostępne nowe zdjęcie. Pamiętaj, że gniazdo nie wyśle zdjęcia, ale tylko link, aby przeglądarka mogła pobrać je asynchronicznie.

W twoim przykładzie wyobraź sobie coś takiego:

Użytkownik (użytkownicy) informuje fotografa, że chce wiedzieć o wszystkich przyszłych zdjęciach
Fotograf mówi przez głośnik, że dostępne jest nowe zdjęcie
Użytkownik prosi fotografa o zdjęcie

To jest trochę jak twoje oryginalne przykładowe rozwiązanie. Jest to bardziej wydajne niż odpytywanie, ponieważ klient nie musi wysyłać żadnych danych do serwera (może z wyjątkiem uderzeń serca ).

Ponadto, jak wspomniano inni, istnieją inne metody, które są lepsze niż proste odpytywanie, które działają w starszych przeglądarkach ( longpolling, i in .)

— korylprince
źródło

43

@RobertHarvey, dlaczego WebSockets nie są powiązane z pytaniem? Pytanie dotyczy tego, czy odpytywanie jest akceptowalną strategią, a obecnie wyraźnie nie jest akceptowalne (a przynajmniej nie optymalne). WebSockets, zdarzenia wysyłane przez serwer i długie odpytywanie działają znacznie lepiej na praktycznie każdym przypadku użycia.

— Fabrício Matté

7

@RobertHarvey, to była tylko moja interpretacja, bez przeróbek, o ile widzę. Jasne, pytanie brzmi: dlaczego jest nadal akceptowane, a nie jaka jest optymalna strategia , ale nadal są one ściśle powiązane z imho.

— Fabrício Matté

25

WebSockets (i tym podobne) są najbliżej implementacji „rozwiązania” PO, więc myślę, że jest to bardzo istotne, mimo że nie wspomniał o tym konkretnie.

— korylprince

6

Nie wspominając, StackExchangewitryny takie jak ta, w której aktualnie się znajdujesz (chyba że patrzysz na tę stronę zapisaną w pamięci podręcznej / zapisaną) WebSockets. Właśnie dlatego zastanawiałem się, dlaczego nikt nie wspomniał o @korylprince WebSockets.

— trysis

6

@ FabrícioMatté: w rzeczywistości nie wszystkie przypadki użycia. Długie odpytywanie wymaga pozostawienia otwartego gniazda dla każdego użytkownika, który zajmuje zasoby systemowe. Usługi fr, które nie są bardzo krytyczne czasowo, ale mają wielu użytkowników, utrzymywanie otwartego gniazda jest zwykle droższe niż obsługa krótkiego 304 co jakiś czas. W przypadku większości usług niewielkie opóźnienie nie stanowi problemu. Pojedyncza maszyna może zwykle obsługiwać więcej klientów z odpytywaniem niż z wypychaniem.

— Lie Ryan,

42

Czasami wystarczająco dobry jest wystarczająco dobry.

Ze wszystkich możliwych sposobów wdrożenia procesu komunikacji „w czasie rzeczywistym” odpytywanie jest być może najprostszym sposobem. Odpytywanie można efektywnie wykorzystać, gdy interwał odpytywania jest stosunkowo długi (tj. Sekundy, minuty lub godziny zamiast chwilowe), a cykle zegara zużywane przez sprawdzanie połączenia lub zasobu tak naprawdę nie mają znaczenia.

— Robert Harvey
źródło

3

To tysiąc razy więcej. Jest akceptowany, ponieważ zwykle jest wystarczająco dobry.

— corsiKa

1

To dość dobra odpowiedź

— Zain R

31

Protokół HTTP jest ograniczony, ponieważ klient MUSI być tym, który inicjuje żądanie. Serwer nie może komunikować się z klientem, chyba że odpowie na żądanie klienta.

Aby dostosować przykład ze świata rzeczywistego, dodaj następujące ograniczenie:

Użytkownik 2 może odpowiedzieć TYLKO na pytania użytkownika 1 za pomocą odpowiedzi w jednym zdaniu, po czym użytkownik 1 musi odejść. Użytkownik 2 nie ma innego sposobu komunikacji.

Z tym nowym ograniczeniem, jak zrobiłbyś to inaczej niż ankietowanie?

— riwalk
źródło

6

HTTP 2.0 będzie obsługiwał wypychania serwera. „Przekazywanie pozwala serwerom wysyłać oświadczenia do klientów bez wyraźnego żądania”. en.wikipedia.org/wiki/HTTP_2.0

— kaptan

5

@kaptan, to świetnie, ale nie jest dostępne. Zrób z tym, co masz.

— riwalk

7

Dostępna jest również funkcja długo odpytywania, która jest obecnie dostępna i symuluje model wypychania za pomocą pull.

— Tim B

24

@dennis: Po napisaniu oprogramowania do automatyzacji przemysłowej chciałbym skomentować twój przykład sondowania czujników. Czujniki odpytywania służą dwóm celom - najbardziej oczywistym jest pobieranie nowych danych. Mniej oczywiste jest wykrycie, że czujnik nadal żyje, nie rozbił się z powodu błędu lub spalania w wyniku pożaru w fabryce lub stopił się w wyniku wypadku przemysłowego. Milczenie, brak odpowiedzi, to także cenne dane.

— slebetman

3

@dennis Czujniki często wykrywają znacznie szybciej niż jesteś zainteresowany danymi. Sondowanie pozwala uzyskać wartość czujnika dokładnie wtedy, kiedy tego chcesz, bez zalewania się aktualizacjami, na których ci nie zależy. (Wyobraź sobie, że system operacyjny powiadamia twoją aplikację za każdym razem, gdy plik zmienia się w dowolnym miejscu na dysku, zamiast aplikacji wymagającej otwarcia i odczytania pliku)

— immibis

13

Dlaczego ankiety są akceptowane? Ponieważ w rzeczywistości każde rozwiązanie jest odpytywaniem niskiego poziomu!

Jeśli serwer powinien cię zaktualizować, gdy tylko pojawią się nowe zdjęcia, zwykle musi mieć połączenie z tobą - ponieważ adresy IP często się zmieniają i nigdy nie wiesz, czy ktoś nie jest już zainteresowany, więc klient musi wysłać jakąś formę sygnał utrzymania, na przykład: „Nadal tu jestem, nie jestem offline”

Wszystkie połączenia stanowe (na przykład TCP / IP) działają tak samo, ponieważ można wysyłać tylko pojedyncze pakiety danych przez Internet; nigdy nie wiadomo, czy druga strona nadal tam jest.

Tak więc każdy protokół ma limit czasu. Jeśli istota nie odpowie w ciągu X sekund, zakłada się, że jest martwa. Więc nawet jeśli masz tylko otwarte połączenie między serwerem a klientem, bez wysyłania żadnych danych, serwer i klient muszą wysyłać regularne pakiety utrzymywania aktywności (jest to obsługiwane na niskim poziomie, jeśli otworzysz połączenie między nimi) - i jak to zrobić to w końcu różni się od ankiet?

Zatem najlepszym podejściem byłoby prawdopodobnie długotrwałe zbieranie:

Klient wysyła żądanie natychmiast po załadowaniu strony (na przykład mówiąc fotografowi „Powiedz mi, czy są jakieś nowe zdjęcia”), ale serwer nie odpowiada, jeśli nie ma żadnych nowych zdjęć. Gdy tylko upłynie limit czasu, klient pyta ponownie.

Jeśli serwer ma teraz nowe zdjęcia, może natychmiast odpowiedzieć wszystkim klientom stojącym w kolejce po nowe zdjęcia. Twój czas reakcji po nowym zdjęciu jest nawet krótszy niż w przypadku wypychania, ponieważ klient nadal czeka w otwartym połączeniu na odpowiedź i nie musisz nawiązywać połączenia z klientem. A żądania odpytywania od klienta nie są znacznie większym ruchem niż stałe połączenie między klientem a serwerem w celu uzyskania odpowiedzi!

— Falco
źródło

Nie zgadzam się, że każde rozwiązanie jest odpytywaniem niskiego poziomu. Mylące jest sondowanie wymagane do wysyłania danych z sondowaniem wymaganym, aby wiedzieć, kiedy klient zaginął. Tak, ten drugi zawsze kończy się odpytywaniem gdzieś na stosie protokołów, ale może to być bardzo mała częstotliwość (na przykład co pięć minut), podczas gdy odpytywanie rzeczywistych danych co sekundę jest marnotrawstwem, którego można uniknąć dzięki prawdziwym powiadomieniom push które NIE odpytuje na żadnym poziomie stosu.

— Allon Guralnek

Pierwsze pakiety typu keepalive są uruchamiane z dość wysoką częstotliwością, ponieważ chcesz uniknąć typowych odstępów czasu, aby kilka sekund nie było rzadkością w przypadku protokołu TCP / IP i prawie wszystko, co nie korzysta z tcp, może być blokowane przez zapory ogniowe. Kiedy więc muszę wysyłać pakiet danych co X sekund, dlaczego nie wypełnić go pewnymi danymi praktycznie bez żadnych kosztów?

— Falco

1

@Guralnek nawet jeśli masz połączenie z interwałem utrzymywania przy życiu wynoszącym 5 minut, limit czasu będzie dłuższy, ponieważ musisz dodać rzeczywiste opóźnienie i utracone pakiety. A serwer utrzyma wiele połączeń przez 5 minut po rozłączeniu się klientów, więc ogólnie będzie to prawdopodobnie kosztować więcej zasobów serwera, jednocześnie oszczędzając jedynie minimalną przepustowość

— Falco

1

+1 za długie odpytywanie. Look up Comet pl.wikipedia.org/wiki/Comet_%28programming%29

— Zan Lynx

9

Jedną z zalet sondowania jest to, że ogranicza szkodę, która może być spowodowana brakiem wiadomości lub usterką stanu. Jeśli X pyta Y o swój stan co pięć sekund, wówczas utrata żądania lub odpowiedzi spowoduje jedynie, że informacja X będzie o dziesięć sekund nieaktualna, a nie 5. Jeśli Y zostanie ponownie uruchomiony, X może dowiedzieć się o tym następnego czas Y jest w stanie odpowiedzieć na jeden z komunikatów X. Jeśli X zostanie zrestartowany, może nigdy nie zadać sobie trudu, by poprosić Y o cokolwiek później, ale ktokolwiek obserwuje status X, powinien rozpoznać, że został zrestartowany.

Jeśli zamiast X odpytujący Y, X polegał na Y, aby poinformować go za każdym razem, gdy zmienił się jego stan, to jeśli stan Y zmienił się i wysłał wiadomość do X, ale z jakiegokolwiek powodu wiadomość ta nie została odebrana, X może nigdy nie być świadomy zmiany . Podobnie, jeśli Y zostanie ponownie uruchomiony i nigdy nie ma powodu, aby wysyłać X wiadomość o czymkolwiek.

W niektórych przypadkach może być pomocne, aby X zażądał, aby Y autonomicznie wysyłał wiadomości o swoim statusie, albo okresowo, albo gdy się zmienia, i miałby sondowanie X tylko, jeśli trwa zbyt długo, nie słysząc nic od Y. Taki projekt może wyeliminować potrzeba, aby X wysłał większość swoich wiadomości (zwykle X powinien przynajmniej od czasu do czasu poinformować Y, że nadal jest zainteresowany otrzymywaniem wiadomości, i Y powinien przestać wysyłać wiadomości, jeśli trwa zbyt długo bez żadnego zainteresowania). Taki projekt wymagałby jednak Y, aby uporczywiezachowują informacje o X, zamiast móc po prostu wysłać odpowiedź temu, kto sondował, a następnie natychmiast zapomnieć o tym, kto to był. Jeśli Y jest systemem wbudowanym, takie uproszczenie może pomóc w wystarczającym zmniejszeniu wymagań dotyczących pamięci, aby umożliwić użycie mniejszego i tańszego kontrolera.

Sondowanie może mieć dodatkową zaletę w przypadku korzystania z potencjalnie zawodnego medium komunikacyjnego (np. UDP lub radia): może w dużej mierze wyeliminować potrzebę potwierdzania warstwy łącza. Jeśli X wysyła Y żądanie statusu Q, Y odpowiada raportem statusu R, a X słyszy R, X nie będzie musiał słyszeć żadnego potwierdzenia warstwy łącza, aby Q wiedział, że zostało odebrane. I odwrotnie, gdy Y wyśle R, nie musi wiedzieć ani przejmować się, czy X go otrzymał. Jeśli X wyśle żądanie statusu i nie otrzyma odpowiedzi, może wysłać kolejne. Jeśli Y wyśle raport, a X go nie usłyszy, X wyśle kolejne żądanie. Jeśli każde żądanie zniknie raz i albo da odpowiedź, albo nie, żadna ze stron nie musi wiedzieć ani przejmować się, czy dana wiadomość została odebrana. Ponieważ wysłanie potwierdzenia może zająć prawie tyle samo przepustowości, co żądanie statusu lub raport, korzystanie z raportu z prośbą w obie strony nie kosztuje dużo więcej niż niezamówiony raport i potwierdzenie. Jeśli X wyśle kilka żądań bez otrzymania odpowiedzi, może w niektórych sieciach z routingiem dynamicznym musi włączyć potwierdzenia na poziomie łącza (i poprosić w swoim żądaniu, aby Y zrobił to samo), aby stos protokołu protokołu mógł rozpoznać problem z dostarczeniem i wyszukać nowa trasa, ale gdy wszystko działa, model zgłoszeń-żądań będzie bardziej wydajny niż stosowanie potwierdzeń na poziomie łącza.

— supercat
źródło

Problem, o którym mówisz z wypychaniem wiadomości Y do X (akapit drugi), można rozwiązać, dołączając numer seryjny do każdej wiadomości. Jeśli wiadomość zostanie utracona, X będzie wiedział, ponieważ nie otrzymał tego numeru seryjnego. W tym momencie może podjąć inne środki w celu synchronizacji z Y. DNS master -> replikacja slave działa w ten sposób.

— korylprince

@korylprince: Każda ze stron może dowiedzieć się o brakującej wiadomości, jeśli druga strona ma okazję coś wysłać (i robi to z powodzeniem) lub jeśli ma powód, aby oczekiwać czegoś od drugiej strony i nigdy jej nie odbierze. Jeśli jedna strona wyśle aktualizację statusu i albo nie wymaga potwierdzeń, albo poddaje się po kilkakrotnym ponowieniu, a druga strona nie spodziewa się zaplanowanych transmisji, druga strona nie będzie wiedziała, że połączenie zniknęło.

— supercat

2

@korylprince - Problem polega na tym, że bez okresowych komunikatów X może wykryć brakujący komunikat dzień później lub rok później lub 10 lat później. Aby wykryć brakujący pakiet w rozsądnym czasie, musisz jakoś sondować. Możesz „pobrać” ankietę lub możesz „pushować” ankietę. Pierwszy nazywa się „odpytywaniem”, drugi nazywa się „biciem serca”

— slebetman

Oba są bardzo prawdziwe. Wszystko zależy od sytuacji.

— korylprince

@slebetman: Bez okresowych wiadomości, jeśli Y zostanie ponownie uruchomiony, może nie istnieć mechanizm, dzięki któremu X mógłby go kiedykolwiek odkryć.

— supercat

1

Pytanie polega na zbilansowaniu liczby niepotrzebnych ankiet względem liczby niepotrzebnych wypychań.

Jeśli sondujesz:

W tej chwili otrzymujesz odpowiedź. Dobrze, jeśli pytasz tylko od czasu do czasu lub potrzebujesz zestawu danych w tym momencie.
Możesz otrzymać odpowiedź „brak zawartości”, co spowoduje bezcelowe obciążenie linii.
Obciążasz linię tylko wtedy, gdy odpytujesz, ale zawsze podczas odpytywania.

Jeśli naciskasz:

Dostarczasz odpowiedź, gdy jest dostępna, co pozwala na natychmiastowe przetwarzanie po stronie klienta.
Możesz dostarczać dane do klientów, którzy nie są zainteresowani tymi danymi, powodując bezsensowne obciążenie linii.
Ładujesz linię za każdym razem, gdy pojawiają się nowe dane, ale tylko wtedy, gdy pojawiają się nowe dane.

Istnieje kilka rozwiązań dotyczących radzenia sobie z różnymi scenariuszami i ich wadami, takich jak na przykład minimalny czas między sondażami, serwery proxy tylko do sondowania, aby zdjąć obciążenie z głównego systemu, lub - w przypadku wypchnięć - rozporządzenie rejestrujące i określające pożądane dane, a następnie wyrejestrowanie podczas wylogowywania. To, które najlepiej pasuje, nie jest ogólnie rzecz biorąc możliwe do powiedzenia, zależy to od systemu.

W twoim przykładzie odpytywanie nie jest najbardziej wydajnym rozwiązaniem, ale najbardziej praktycznym. Bardzo łatwo jest napisać system odpytywania w JavaScript i bardzo łatwo wdrożyć go również po stronie dostawy. Serwer stworzony do dostarczania danych obrazu powinien być w stanie obsłużyć dodatkowe żądania, a jeśli nie, może być skalowany liniowo, ponieważ dane są w większości statyczne i dlatego mogą być łatwo buforowane.

Metoda wypychania implementująca logowanie, opis potrzebnych danych i wreszcie wylogowanie byłaby najbardziej wydajna, ale prawdopodobnie jest zbyt złożona dla przeciętnego „skrypciarza” i musi poradzić sobie z pytaniem: co jeśli użytkownik po prostu wyłącza przeglądarkę i nie można się wylogować?

Może lepiej jest mieć więcej użytkowników (ponieważ dostęp jest łatwy) niż zaoszczędzić trochę pieniędzy na innym serwerze pamięci podręcznej?

— TwoThe
źródło

1

Z jakiegoś powodu w dzisiejszych czasach wydaje się, że wszyscy młodsi programiści zapomnieli lekcji z przeszłości i dlaczego niektóre rzeczy ewoluowały w taki sposób.

Problemem była przepustowość
Połączenie może być przerywane.
Przeglądarki nie miały tak dużej mocy obliczeniowej
Istnieją inne metody dostępu do treści. Sieć nie jest w3.

W obliczu tych ograniczeń możesz nie mieć stałej komunikacji dwukierunkowej. A jeśli spojrzysz na model OSI, przekonasz się, że większość rozważań ma na celu oddzielenie trwałości od podstawowego połączenia.

Mając to na uwadze, metoda pobierania informacji przez sondowanie jest doskonałym sposobem na zmniejszenie przepustowości i obliczeń po stronie klienta. Wzrost push jest tak naprawdę w przeważającej części tylko tym, że klient dokonuje ciągłego odpytywania lub gniazd sieciowych. Osobiście, gdybym był tam wszystkim, doceniłbym regularność odpytywania jako środka analizy ruchu, w którym przekroczenie czasu żądania GET / POST zasygnalizowałoby mężczyznę w jakiejś środkowej sytuacji.

— konto gościa
źródło