2015-12-31 12 views
5

Sto provando a trasmettere audio al mio server e poi lo streaming su un servizio specificato dall'utente, l'utente mi fornirà someHostName, che a volte può non supportare quel tipo di richiesta.readable.on ('end', ...) non viene mai attivato

Il mio problema è che quando succede il clientRequest.on('end',..) non è mai sparato, penso che sia perché è di essere convogliato a someHostReq che viene incasinato quando someHostName è "sbagliato".

La mia domanda è:

C'è qualche cosa che posso ancora avere clientRequest.on('end',..) sparato anche quando le flusso clientRequest tubi a ha qualcosa che non va?

In caso contrario: come faccio a rilevare che qualcosa di sbagliato è successo con someHostReq "immediatamente"? someHostReq.on('error') non si avvia tranne dopo un po 'di tempo.

codice:

someHostName = 'somexample.com' 

    function checkIfPaused(request){//every 1 second check .isPaused 
     console.log(request.isPaused()+'>>>>'); 
     setTimeout(function(){checkIfPaused(request)},1000); 
    } 

    router.post('/', function (clientRequest, clientResponse) { 
     clientRequest.on('data', function (chunk) { 
      console.log('pushing data'); 
     }); 

     clientRequest.on('end', function() {//when done streaming audio 
      console.log('im at the end'); 
     }); //end clientRequest.on('end',) 

     options = { 
      hostname: someHostName, method: 'POST', headers: {'Transfer-Encoding': 'chunked'} 
     }; 

     var someHostReq = http.request(options, function(res){ 
      var data = '' 
      someHostReq.on('data',function(chunk){data+=chunk;}); 
      someHostReq.on('end',function(){ 
       console.log('someHostReq.end is called'); 
      }); 
     }); 
     clientRequest.pipe(someHostReq); 
     checkIfPaused(clientRequest); 
    }); 

uscita:

nel caso di un corretto hostname:

pushing data 
    . 
    . 
    pushing data 
    false>>> 
    pushing data 
    . 
    . 
    pushing data 
    pushing data 
    false>>> 
    pushing data 
    . 
    . 
    pushing data 
    console.log('im at the end'); 
    true>>> 
    //continues to be true, that's fine 

nel caso di un nome host sbagliato:

pushing data 
    . 
    . 
    pushing data 
    false>>>> 
    pushing data 
    . 
    . 
    pushing data 
    pushing data 
    false>>>> 
    pushing data 
    . 
    . 
    pushing data 
    true>>>> 
    true>>>> 
    true>>>> 
    //it stays true and clientRequest.on('end') is never called 
    //even tho the client is still streaming data, no more "pushing data" appears 

se pensi che la mia domanda sia un duplicato:

È possibile passare alla modalità scorre effettuando una delle seguenti operazioni:

Aggiunta di un gestore eventi "dati" per l'ascolto dei dati.

Chiamare il metodo resume() per aprire esplicitamente il flusso.

Chiamare il metodo pipe() per inviare i dati a un Writable.

fonte: https://nodejs.org/api/stream.html#stream_class_stream_readable

+0

hai provato ad ascoltare 'chiudi 'invece? – aarosil

+0

che cos'è lisyen close thread? Lo stream – bubakazouba

+0

ha evento 'close' e ​​anche 'end', vedi dettagli [qui] (https://nodejs.org/api/stream.html#stream_class_stream_readable) – aarosil

risposta

1

Il comportamento in caso di un nome host sbagliato sembra qualche problema con la buffer, se il buffer del flusso di destinazione è pieno (poiché someHost non riceve i blocchi di dati inviati) la pipe non continuerà a leggere il flusso di origine perché pipe gestisce automaticamente il flusso. Poiché pipe non sta leggendo il flusso di origine non si raggiunge mai l'evento 'end'.

C'è qualche cosa che posso ancora avere clientRequest.on ('fine', ..) sparato anche quando i tubi di flusso clientRequest a ha qualcosa che non va con esso?

L'evento di fine non viene attivato a meno che i dati non vengano completamente consumati. Per ottenere la "fine" attivata con uno streaming in pausa, è necessario chiamare resume() (disattivando prima il nome host errato o il buffer si bloccherà nuovamente) per impostare nuovamente il vapore in flowMode o read() alla fine.

Ma come rilevare quando dovrei fare uno dei precedenti?

someHostReq.on ('errore') è il luogo naturale, ma se ci vuole troppo tempo per accendere:

Prima tenta di impostare una richiesta basso timeout (meno di someHostReq.on ('errore') prende per innescare, come sembra troppo tempo per voi) request.setTimeout(timeout[, callback]) e verificare se non fallisce quando il nome host corretto. Se funziona, basta usare l'evento callback o timeout per rilevare quando il timeout del server e utilizzare una delle tecniche di cui sopra per raggiungere fino alla fine.

Se la soluzione timeOut non riesce o non si adatta alle vostre esigenze si deve giocare con le bandiere in clientRequest.on('data'), clientRequest.on('end') e/o clienteRequest.isPaused di indovinare quando si sono bloccati dal buffer. Quando pensi di essere bloccato, applica una delle tecniche sopra riportate per raggiungere la fine del flusso. Fortunatamente ci vuole meno tempo per rilevare il buffer bloccato che aspettare someHostReq.on('error') (forse due request.isPaused() = true senza raggiungere l'evento 'data' è sufficiente per determinare se sei bloccato).

Come faccio a rilevare che qualcosa di sbagliato è accaduto con someHostReq "subito"? someHostReq.on ('errore') non si attiva tranne dopo il qualche volta.

Gli errori si attivano quando si attivano i trigger. Non è possibile "immediatamente" rilevarlo. Perché non inviare semplicemente una richiesta di verifica per verificare il supporto prima di trasmettere i flussi? Una specie di:

"Servizio di condizionamento specificato dall'utente ..." If OK -> Convoglia il flusso di richiesta utente al servizio OR FAIL -> Notifica all'utente di un servizio errato.

Problemi correlati