Drop or reject lightweight connections
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- haskell
- Bereich
- distributed-systems
Rechercherichtung
Beginne damit, das zugehörige Issue haskell-distributed/distributed-process#434 zu lesen und den Aufbau von lightweight-connection sowie den bestehenden control-code-Handshake nachzuverfolgen. Ermittle, wie ein Peer eine neue Verbindung akzeptieren oder ablehnen kann, ohne bestehende Verbindungen zu trennen, und bewerte die Latenzbedenken. Als erledigt gilt die Aufgabe, wenn das angeforderte Verhalten spezifiziert und implementiert ist und die Annahme und Ablehnung durch Tests abgedeckt sind.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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?
- Vorherrschende Sprache
- Haskell
- Sterne
- 753
- Forks
- 101
- Ø Merge
- 1 T. 3 Std.
- Gemergte PRs (30 T.)
- 4
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus haskell-distributed/distributed-process
-
enhancement Feature Request
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
haskell-distributed/distributed-process#486 · 1 Kommentar · 1 Reaktion ·
-
discuss enhancement Feature Request
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
haskell-distributed/distributed-process#478 · 4 Kommentare · 3 Reaktionen ·
-
enhancement Feature Request
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 15/100
haskell-distributed/distributed-process#476 · 2 Reaktionen ·
-
Demonstrating the use of Cloud Haskell for a Raft implementationEvtl. wieder frei @LaurentRDC hat das vor 481 Tagen übernommen, und es ist kein Pull Request offen. Offenenhancement Feature Request
haskell-distributed/distributed-process#475 · 3 Reaktionen · 1 zugewiesene Person ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 20/100
haskell-distributed/distributed-process#473 · 4 Kommentare · 1 Reaktion ·
Alle Issues in haskell-distributed/distributed-process
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
objectionary/phino#2059 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
NixOS/nixpkgs-update#586 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 83/100
wireapp/wire-server#5632 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100