Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Broadcaster Initiated Connections

Aperta
  • Qualcosa non va?
#34 3 commenti 2 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
go
Ambito
audio-video-rtc, distributed-systems, networking

Direzione di ricerca

Inizia esaminando il comportamento attuale del transcoder descritto nel commento collegato da go-livepeer-basicnet issue #21, quindi confrontalo con il flusso avviato dal broadcaster proposto qui. Il lavoro è completato quando il design del protocollo supporta le richieste TranscodeReq avviate dal broadcaster e non pubblica più on-chain le informazioni di rete del broadcaster.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Rationale

Handling failure cases in the current implementation is difficult (eg, transcoder address changes, broadcaster unavailability), and poses challenges for designing large-scale systems.

Broadcasters are overly exposed to the network (their Node ID is public), while transcoders could be exposed more given their role as providers of infrastructure. Reverse this dynamic.

This proposal solves these issues simultaneously. The specific challenges in the current network protocol are elaborated below, in the context of the proposal's benefits.

Proposal

  • Publish transcoder network information on-chain (or in a similarly verifiable location). This could be the node ID, the address, etc.
  • The broadcaster initiates the messaging to the transcoder when it's ready to stream a job. Eg, turn the flow into this:
    • Broadcaster sends TranscodeReq(JobInfo) request
    • Transcoder sends a TranscodeAck(ConnectionInfo) response
    • Broadcaster establishes a direct connection using ConnectionInfo
    • Broadcaster streams segments to transcoder
  • Remove the broadcaster network information from the chain (StreamID).

For reference to the current transcoder behavior, see the proposal here https://github.com/livepeer/go-livepeer-basicnet/issues/21#issuecomment-369310870 . In summary:

  • Old flow Transcoder initiated connection, where the transcoder sends TranscodeSub to the broadcaster.
  • Proposed flow Broadcaster initiated connection, where the broadcaster sends TranscodeReq to the transcoder.
Benefits, as related to the role of the transcoder

Given the limited pool size, transcoder operators are likely to run multiple physical nodes to accommodate higher demand. A given transcoder Eth address could correspond to any number of nodes.

  • Load balancing. Upon starting a broadcast, the transcoder can direct the broadcaster to connect to a particular node when the broadcaster is ready, rather than deciding that node in advance when the job is created. This would also make it much easier to update the assigned node mid-job (read below for details).
  • Failover. If the connection dies, the broadcaster can re-request a new address, and re-establish the connection. This also greatly simplifies the systems architecture for a transcoder operator: the operator doesn't have to keep track of each node's state up-to-the-moment. If a node fails, the transcoder doesn't have to do anything to re-create the node's connection state; it can simply wait for broadcasters to send a request in again, and direct them around the failed node.
Benefits, as related to the role of the broadcaster

The broadcaster knows exactly when it's going to need a transcoder. Let the broadcaster drive that; take the onus of initiating the job off the transcoder.

  • Works better with our expectations of broadcaster uptime.
    • Transcoders are expected to be continually available. Not so for broadcasters. Broadcasters aren't providing infrastructure, while transcoder operators are.
  • The broadcaster does not need to be online or maintain an active connection to the transcoder.
    • Solves the question of what to do if a direct connection breaks (eg, broadcaster takes a break) or the broadcaster goes offline. The transcoder does not need to do anything. Avoids network spam in case the transcoder needs to publish updated information if the broadcaster is offline (read below).
  • Following the expectation of broadcaster uptime: TranscodeSub, as specified, will lead to periodic spamming on the network if a broadcaster isn't ready to stream a job (eg, isn't online immediately after a job is created), or if the transcoder's connection information has changed.
    • In particular, extremely long job durations impose an expensive externality on the network: we could be flooded with unacknowledged requests for thousands of dead-end transcoding jobs. Since these broadcasters could come online or acknowledge the transcoder (via direct connection) at any moment, we can't simply stop sending these TranscodeSub messages.
  • With that being said on broadcaster availability, this would also be a better fit for delayed broadcasting https://github.com/livepeer/go-livepeer/issues/316
  • The broadcaster node ID no longer needs to be public, and the broadcaster doesn't need to be exposed online waiting for messages from the transcoder.
    • This is a good thing! Gives broadcasters additional flexibility and reduces their operational / security burden. All they need to carry around are their Eth signing keys, rather than some abstract notion of node ID. This makes broadcaster 'portability' much easier. We also expect transcoders to be much more engaged with the mechanics of running the network, since they are providing the infrastructure. The broadcaster doesn't need to know that burden. Related: https://github.com/livepeer/go-livepeer-basicnet/issues/31
Additional Future Potential
  • Segues better into an off-chain transcoder selection mechanism. For example, we could submit a set of encoding specifications (in terms of our 'gas accounting' units), and transcoders could respond with a price. The broadcaster can then choose which transcoder to initiate a direct connection to. With the current TranscodeSub mechanism, this would require another set of round-trips to ack the job.
  • Beginnnings of a transcoder availability mechanism. The broadcaster could try another transcoder if the transcoder NACKs or is otherwise unresponsive. This solves the problem inherent to the broadcaster losing the gas they spent to submit the job if the assigned transcoder is unavailable.
Lingua principale
Go
Stelle
18
Fork
6
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livepeer/go-livepeer-basicnet

Tutte le issue di livepeer/go-livepeer-basicnet

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.