Drop or reject lightweight connections
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- haskell
- Área
- distributed-systems
Línea de trabajo
Empieza leyendo el issue relacionado haskell-distributed/distributed-process#434 y siguiendo la configuración de lightweight-connection y el handshake existente de control-code. Determina cómo puede un peer aceptar o rechazar una nueva conexión sin cerrar las conexiones existentes, y evalúa la preocupación por la latencia. Se considera terminado cuando el comportamiento solicitado está especificado e implementado, con cobertura para la aceptación y el rechazo.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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?
- Lenguaje dominante
- Haskell
- Estrellas
- 753
- Forks
- 101
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de haskell-distributed/distributed-process
-
enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
haskell-distributed/distributed-process#486 · 1 comentario · 1 reacción ·
-
discuss enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
haskell-distributed/distributed-process#478 · 4 comentarios · 3 reacciones ·
-
enhancement Feature Request
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
haskell-distributed/distributed-process#476 · 2 reacciones ·
-
Demonstrating the use of Cloud Haskell for a Raft implementationQuizá libre de nuevo @LaurentRDC la tomó hace 482 días y no hay ningún pull request abierto. Abiertoenhancement Feature Request
haskell-distributed/distributed-process#475 · 3 reacciones · 1 asignado ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
haskell-distributed/distributed-process#473 · 4 comentarios · 1 reacción ·
Todos los issues de haskell-distributed/distributed-process
Issues similares
-
MorphRule, DataizeRule and ContextualizeRule silently accept unknown YAML keys, unlike rewrite `Rule`Posiblemente ocupada @renyamamoto2026-cmyk la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
objectionary/phino#2107 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
tweag/tricorder#640 · 1 comentario ·
Los mantenedores suelen responder en 1 día