Jak facebook, gmail wysyła powiadomienia w czasie rzeczywistym?

Update

Ponieważ nadal otrzymuję głosy na ten temat, myślę, że rozsądne jest pamiętać, że ta odpowiedź ma 4 lata. Sieć rozrosła się w bardzo szybkim tempie, więc proszę pamiętać o tej odpowiedzi.

Miałem ten sam problem Ostatnio i badałem na ten temat.

Podane rozwiązanie nazywa się long polling, a aby poprawnie z niego korzystać, musisz mieć pewność, że twoje żądanie AJAX ma "duży" limit czasu i zawsze wykonywać to żądanie po bieżącym zakończeniu (timeout, błąd lub sukces).

Long Ankiet-Klient

Tutaj, aby Kod był krótki, użyję jQuery:

function pollTask() { 

    $.ajax({

        url: '/api/Polling',
        async: true,            // by default, it's async, but...
        dataType: 'json',       // or the dataType you are working with
        timeout: 10000,          // IMPORTANT! this is a 10 seconds timeout
        cache: false

    }).done(function (eventList) {  

       // Handle your data here
       var data;
       for (var eventName in eventList) {

            data = eventList[eventName];
            dispatcher.handle(eventName, data); // handle the `eventName` with `data`

       }

    }).always(pollTask);

}

Należy pamiętać, że (z jQuery docs):

W jQuery 1.4.x i poniżej, obiekt XMLHttpRequest będzie w stan nieprawidłowy, jeśli żądanie się kończy; dostęp do jakichkolwiek elementów obiektu może rzucić wyjątek. Tylko w Firefoksie 3.0+, skrypt i JSONP żądania nie mogą być anulowane przez limit czasu; skrypt uruchomi się nawet jeśli pojawia się po okresie czasu.

Long Ankiet-Serwer

Nie jest w żadnym konkretnym języku, ale byłoby to coś takiego:

function handleRequest () {  

     while (!anythingHappened() || hasTimedOut()) { sleep(2); }

     return events();

} 

Tutaj hasTimedOut upewni się, że Twój kod nie będzie czekał w nieskończoność, a anythingHappened sprawdzi, czy doszło do jakiegoś zdarzenia. {[4] } jest za zwolnienie wątku, aby robić inne rzeczy, podczas gdy nic się nie dzieje. events zwróci słownik zdarzeń (lub dowolną inną strukturę danych, którą wolisz) w formacie JSON (lub dowolnym innym woli).

To z pewnością rozwiązuje problem, ale jeśli martwisz się o skalowalność i wydajność, tak jak ja podczas badań, możesz rozważyć inne rozwiązanie, które znalazłem.

Rozwiązanie

Użyj gniazd!

Po stronie klienta, aby uniknąć problemów ze zgodnością, użyj socket.io . próbuje używać gniazda bezpośrednio i ma alternatywy dla innych rozwiązań, gdy gniazda nie są dostępne.

Po stronie serwera Utwórz serwer używając NodeJS (przykład tutaj ). Klient zasubskrybuje ten kanał (observer) utworzony wraz z serwerem. Za każdym razem, gdy powiadomienie ma zostać wysłane, jest ono publikowane na tym kanale, a subskrybent (Klient) zostaje powiadomiony.

Facebook Facebook wykorzystuje technologię comet do "wypychania" Wiadomości do przeglądarek internetowych. Serwer Comet Facebook jest zbudowany na otwartym serwerze Erlang Web Server mochiweb.

Na poniższym obrazku wyrażenie "klastry kanałów" oznacza "serwery komet".

Możesz wypróbować icomet , Serwer c1000k C++ comet zbudowany z libevent. icomet zapewnia również bibliotekę JavaScript, jest łatwy w użyciu tak proste, jak:

var comet = new iComet({
    sign_url: 'http://' + app_host + '/sign?obj=' + obj,
    sub_url: 'http://' + icomet_host + '/sub',
    callback: function(msg){
        // on server push
        alert(msg.content);
    }
});

Facebook używa MQTT zamiast HTTP. Popychanie jest lepsze niż sondażowanie. Poprzez HTTP musimy nieustannie sprawdzać serwer, ale poprzez serwer MQTT wypycha wiadomość do klientów.

Porównanie między MQTT i HTTP: http://www.youtube.com/watch?v=-KNPXPmx88E

Uwaga: moje odpowiedzi najlepiej pasują do urządzeń mobilnych.

Ważną kwestią przy długich sondażach jest obsługa błędów. Istnieją dwa rodzaje błędów:

1. W takim przypadku Klient powinien natychmiast przywrócić połączenie. Jest to normalne wydarzenie w długich sondażach, gdy nie dotarły żadne wiadomości.

2. Błąd sieci lub błąd wykonania. Jest to rzeczywisty błąd, który klient powinien z wdzięcznością zaakceptować i poczekać, aż serwer wróci on-line.

Główne problem polega na tym, że jeśli twój handler błędów natychmiast przywróci połączenie również dla błędu typu 2, klienci będą DOS serwera.

Obie odpowiedzi z próbką kodu tego nie rozumieją.

function longPoll() { 
        var shouldDelay = false;

        $.ajax({
            url: 'poll.php',
            async: true,            // by default, it's async, but...
            dataType: 'json',       // or the dataType you are working with
            timeout: 10000,          // IMPORTANT! this is a 10 seconds timeout
            cache: false

        }).done(function (data, textStatus, jqXHR) {
             // do something with data...

        }).fail(function (jqXHR, textStatus, errorThrown ) {
            shouldDelay = textStatus !== "timeout";

        }).always(function() {
            // in case of network error. throttle otherwise we DOS ourselves. If it was a timeout, its normal operation. go again.
            var delay = shouldDelay ? 10000: 0;
            window.setTimeout(longPoll, delay);
        });
}
longPoll(); //fire first handler