Il polling lungo è possibile in Google App Engine?

Question

Ho bisogno di creare un'applicazione che ha bisogno di interrogare il server spesso, ma GAE ha delle limitazioni sulle richieste, quindi fare molte richieste potrebbe essere molto costoso. È possibile utilizzare il polling lungo e fare richieste attendere il massimo 30 secondi per le modifiche?

Answer 1

Google AppEngine ha una nuova API funzione del canale, con che avete un possibility to build a good realtime application.

Un'altra soluzione è utilizzare un server comet di terze parti come mochiweb o intrecciato con un modello iframe.

Client1, in attesa di un evento:

client1 --Iframe Pattern--> Erlang/Mochiweb(HttpLongPolling): 

Client2, l'invio di un messaggio:

client2 --XhrIo--> AppEngine --UrlFetch--> Erlang/Mochiweb 

Per utilizzare mochiweb con il modello cometa, Richard Jones ha scritto un buon argomento (su google: Richard Jones: un'applicazione per la cometa da milioni di utenti).

Answer 2

Non penso che il polling lungo sia possibile. Il timeout della richiesta predefinito per google appengine è di 30 secondi. Nel polling lungo se il messaggio impiega più di 30 secondi per generare, allora fallirà. Probabilmente stai meglio usando il polling breve.

Un altro approccio consiste nel "simulare" il polling lungo con il limite di 30 secondi. Per fare ciò se un messaggio non arriva entro 20 secondi, il server può inviare un messaggio "token" al posto di un messaggio normale, richiedendo al client di consumarlo e riconnettersi.

sembra che ci sia feature request (e la sua accettato) su google AppEngine per polling lungo

Answer 3

Abbiamo provato a implementare una soluzione di polling a lungo simile a Comet su App Engine, con risultati misti.

def wait_for_update(request, blob): 
    """ 
    Wait for blob update, if wait option specified in query string. 
    Otherwise, return 304 Not Modified. 
    """ 
    wait = request.GET.get('wait', '') 
    if not wait.isdigit(): 
     return blob 
    start = time.time() 
    deadline = start + int(wait) 
    original_sha1 = blob.sha1 
    try: 
     while time.time() < deadline: 
      # Sleep one or two seconds. 
      elapsed = time.time() - start 
      time.sleep(1 if elapsed < 7 else 2) 
      # Try to read updated blob from memcache. 
      logging.info("Checking memcache for blob update after %.1fs", 
         elapsed) 
      blob = Blob.cache_get_by_key_name(request.key_name) 
      # Detect changes. 
      if blob is None or blob.sha1 != original_sha1: 
       break 
    except DeadlineExceededError: 
     logging.info("Caught DeadlineExceededError after %.1fs", 
        time.time() - start) 
    return blob 

Il problema che sto vedendo è che le richieste a seguito di un lungo polling, sono sempre serialize (sincronizzato) dietro la richiesta a lungo polling. Posso osservare una traccia in Chrome e vedere una timeline come questa:

1. Richiesta 1 inviata. GET (non modificato) blob (attendere fino a modifica).
2. Richiesta 2 inviata. Modifica il BLOB.
3. Dopo il timeout completo, la richiesta 1 restituisce (dati non modificati).
4. La richiesta 2 viene elaborata sul server e restituisce esito positivo.

Ho usato Wireshark e Chrome/sequenza temporale per confermare che io mando la richiesta di modifica al server su una connessione TCP distinto dal lungo polling. Quindi questa sincronizzazione deve essere saltata sul server di produzione di App Engine. Google non documenta questo dettaglio del comportamento del server, per quanto ne so.

Penso che attendere l'API del canale è la migliore speranza che abbiamo di ottenere un buon comportamento in tempo reale da App Engine.