Drop or reject lightweight connections
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- haskell
- Ambito
- distributed-systems
Direzione di ricerca
Inizia leggendo la issue correlata haskell-distributed/distributed-process#434 e tracciando la configurazione di lightweight-connection e l’handshake esistente di control-code. Determina come un peer possa accettare o rifiutare una nuova connessione senza interrompere le connessioni esistenti e valuta la preoccupazione relativa alla latenza. Il lavoro è completato quando il comportamento richiesto è specificato e implementato, con una copertura per l’accettazione e il rifiuto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
This is similar to haskell-distributed/distributed-process#434 but instead of dropping a bundle of connections to a peer, I'd like to be able to drop or reject one lightweight connection. This could be useful in case, for instance, a node is under heavy load and would like to continue to accept data on existing connections (perhaps some more data is needed) but reject new connections until the load is lessened.
Seems to me this would require a handshake when setting up lightweight connections. Currently if there's already a heavyweight connection to a peer then one simply sends a control code and then the connection is judged to be up and running, no response is expected. To allow rejection of the connection, the connector would have to wait for a yes or no response from the peer. Maybe this extra latency is unacceptable?
- Lingua principale
- Haskell
- Stelle
- 753
- Fork
- 101
- Merge medio
- 1g 3h
- PR unite (30g)
- 4
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di haskell-distributed/distributed-process
-
enhancement Feature Request
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
haskell-distributed/distributed-process#486 · 1 commento · 1 reazione ·
-
discuss enhancement Feature Request
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
haskell-distributed/distributed-process#478 · 4 commenti · 3 reazioni ·
-
enhancement Feature Request
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
haskell-distributed/distributed-process#476 · 2 reazioni ·
-
Demonstrating the use of Cloud Haskell for a Raft implementationForse di nuovo libera @LaurentRDC l’ha presa 482 giorni fa e non c’è nessuna pull request aperta. Apertaenhancement Feature Request
haskell-distributed/distributed-process#475 · 3 reazioni · 1 assegnatario ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
haskell-distributed/distributed-process#473 · 4 commenti · 1 reazione ·
Tutte le issue di haskell-distributed/distributed-process
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
objectionary/phino#2059 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
NixOS/nixpkgs-update#586 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 83/100
wireapp/wire-server#5632 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100