Il client risponde sempre al precedente evento inviato dal server, non all'evento corrente

Question

Vedo un comportamento strano con il codice here.

lato client (JavaScript):

<input type="text" id="userid" placeholder="UserID" /><br />` 
<input type="button" id="ping" value="Ping" /> 

<script> 
    var es = new EventSource('/home/message'); 
    es.onmessage = function (e) { 
     console.log(e.data); 
    }; 
    es.onerror = function() { 
     console.log(arguments); 
    }; 
    $(function() { 
     $('#ping').on('click', function() { 
      $.post('/home/ping', { 
       UserID: parseInt($('#userid').val()) || 0 
      }); 
     }); 
    }); 
</script> 

lato server (C#):

using System; 
using System.Collections.Concurrent; 
using System.Threading; 
using System.Web.Mvc; 
using Newtonsoft.Json; 

namespace EventSourceTest2.Controllers { 
    public class PingData { 
     public int UserID { get; set; } 
     public DateTime Date { get; set; } = DateTime.Now; 
    } 

    public class HomeController : Controller { 
     public ActionResult Index() { 
      return View(); 
     } 

     static ConcurrentQueue<PingData> pings = new ConcurrentQueue<PingData>(); 

     public void Ping(int userID) { 
      pings.Enqueue(new PingData { UserID = userID }); 
     } 

     public void Message() { 
      Response.ContentType = "text/event-stream"; 
      do { 
       PingData nextPing; 
       if (pings.TryDequeue(out nextPing)) { 
        var msg = "data:" + JsonConvert.SerializeObject(nextPing, Formatting.None) + "\n\n"; 
        Response.Write(msg); 
       } 
       Response.Flush(); 
       Thread.Sleep(1000); 
      } while (true); 
     } 
    } 
} 

Una volta che ho premuto il ping per aggiungere un nuovo elemento alla coda pings, il ciclo all'interno del metodo Message seleziona il nuovo oggetto ed emette un evento, tramite Response.Write (confermato utilizzando Debug.Print sul server). Tuttavia, il browser non attiva onmessage fino a quando non preme il ping una seconda volta e il browser emette un altro evento; a questo punto i dati dal primo evento raggiungono onmessage.

Come posso risolvere questo?

---

Per chiarire, questo è il comportamento che ci si aspetterebbe:

Client      Server 
------------------------------------------------------------------- 
Press Ping button 
XHR to /home/ping 
          Eneque new item to pings 
          Message loop issues server-sent event 
EventSource calls onmessage 

Questo è ciò che sta realmente accadendo:

Client      Server 
------------------------------------------------------------------- 
Press Ping button 
XHR to /home/ping 
          Eneque new item to pings 
          Message loop issues server-sent event 
(Nothing happens) 
Press Ping button again 
New XHR to /home/ping 
EventSource calls onmessage with previous event data 

(Durante l'esecuzione in Chrome richiesta message è elencato in la scheda Rete come sempre in sospeso. Non sono sicuro se questo è il comportamento normale degli eventi inviati dal server o forse è correlato al problema.)

Modifica

La rappresentazione della stringa della variabile msg dopo Response.Write assomiglia a questo:

"data:{\"UserID\":105,\"Date\":\"2016-03-11T04:20:24.1854996+02:00\"}\n\n" 

compreso molto chiaramente le nuove righe.

Answer 1

io non sono sicuro se questo funzionerà, perché non posso provarlo subito, ma per quanto riguarda per aggiungere un fine ?:

Response.Flush(); 
Response.End(); 

Answer 2

EDIT: La prego quindi di provare a creare l'oggetto e poi passando ad Enqueue? Come in:

PingData myData = new PingData { UserID = userID }; 
pings.Enqueue(myData); 

Ci potrebbe essere qualcosa di strano in cui Dequeue pensa è fatto il lavoro ma l'oggetto non è correttamente PingData ancora costruito.

Inoltre, è possibile provare console.log("I made it to the function") anziché console.log(e.data).

---- informazioni precedenti richieste di seguito ----

Si prega di accertarsi che il server di Debug.Print conferma questa riga di codice:

Response.Write("data:" + JsonConvert.SerializeObject(nextPing, Formatting.None) + "\n\n"); 

venga effettivamente eseguita? Si prega di ricontrollare questo. Se riesci a catturare la risposta inviata dal server, allora possiamo vedere di cosa si tratta?

Inoltre, possiamo vedere quali browser sono stati testati? Non tutti i browser supportano eventi del server.

Answer 3

Questa non è una risposta per dire, ma spero che ne porti uno. Sono stato in grado di farlo funzionare con il seguente codice.

public void Ping(int id) 
{ 
    pings.Enqueue(new PingData { ID = id }); 
    Response.ContentType = "text/plain"; 
    Response.Write("id received"); 
} 
public void Message() 
{ 
    int count = 0; 
    Response.ContentType = "text/event-stream"; 
    do { 
     PingData nextPing; 
     if (pings.TryDequeue(out nextPing)) { 
      Response.ClearContent(); 
      Response.Write("data:" + nextPing.ID.ToString() + " - " + nextPing.Date.ToLongTimeString() + "\n\n"); 
      Response.Write("event:time" + "\n" + "data:" + DateTime.Now.ToLongTimeString() + "\n\n"); 
      count = 0; 
      Response.Flush(); 
     } 
     if (!Response.IsClientConnected){break;} 
     Thread.Sleep(1000); 
     count++; 
    } while (count < 30); //end after 30 seconds of no pings 
} 

La riga di codice che fa la differenza è il secondo Response.Write. Il messaggio non viene visualizzato nel browser fino al prossimo ping simile al problema, ma il ping viene sempre visualizzato. Senza questa linea il ping apparirà solo dopo il ping successivo, oppure una volta che il mio contatore da 30 secondi si esaurirà.

Il messaggio mancante che appare dopo il timer di 30 secondi mi porta a concludere che questo è un problema .Net, o c'è qualcosa che ci manca. Non sembra essere un problema di origine degli eventi perché il messaggio appare su un evento del server e non ho avuto problemi con SSE con PHP.

Per riferimento, ecco il codice JavaScript e HTML con cui ho provato.

<input type="text" id="pingid" placeholder="ID" /><br /> 
<input type="button" id="ping" value="Ping" /> 

<div id="timeresponse"></div> 
<div id="pingresponse"></div> 

<script> 
    var es = new EventSource('/Home/Message'); 
    es.onmessage = function (e) { 
     console.log(e.data); 
     document.getElementById('pingresponse').innerHTML += e.data + " - onmessage<br/>"; 
    }; 
    es.addEventListener("ping", function (e) { 
     console.log(e.data); 
     document.getElementById('pingresponse').innerHTML += e.data + " - onping<br/>"; 
    }, false); 
    es.addEventListener("time", function (e) { 
     document.getElementById('timeresponse').innerHTML = e.data; 
    }, false); 
    es.onerror = function() { 
     console.log(arguments); 
     console.log("event source closed"); 
     es.close(); 
    }; 
    window.onload = function(){ 
     document.getElementById('ping').onclick = function() { 
      var xmlhttp = new XMLHttpRequest(); 
      xmlhttp.onload = function() { 
       console.log(this.responseText); 
      }; 
      var url = '/Home/Ping?id=' + document.getElementById('pingid').value; 
      xmlhttp.open("GET", url); 
      xmlhttp.send(); 
     }; 
    }; 
</script> 

Answer 4

Il comportamento predefinito di .net è di serializzare l'accesso allo stato di sessione. Blocca l'esecuzione parallela. Le richieste vengono elaborate in sequenza e l'accesso allo stato della sessione è esclusivo per la sessione. È possibile sovrascrivere lo stato predefinito per classe.

[SessionState(SessionStateBehavior.Disabled)] 
public class MyPulsingController 
{ 
} 

C'è un esempio di questo nella questione here.

Answer 5

Poiché un evento è solo dati di testo, la mancanza della doppia interruzione di riga prima che il primo evento venga scritto per la risposta potrebbe influire sul client. L'esempio da mdn docs suggerisce

header("Content-Type: text/event-stream\n\n"); 

che potrebbe essere applicato applicano alla risposta NET manipolazione (notare gli effetti collaterali di Response.ClearContent()).

Se ci si sente troppo hacky, si potrebbe iniziare il vostro flusso con un commento keep-alive (se si vuole evitare timeout potrebbe essere necessario inviare periodicamente commenti):

: just a keep-alive comment followed by two line-breaks, Response.Write me first