responsible neighborhood splitting

Abierto
  • ¿Algo no está bien?
#4,758 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
go
Área
distributed-systems

Línea de trabajo

Start by reading the linked SWIP and tracing Bee's reserve eviction and storage-radius logic, then locate the pullsync and pushsync workers and their topology-change handling. The issue does not name files or tests, so first map those entry points and existing protocol tests. Done means radius growth avoids empty neighborhoods and both protocols pause or reject work as specified until the split problem is resolved.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Background

Swip https://github.com/ethersphere/SWIPs/pull/43

When the reserve capacity is reached, the reserve will go through an eviction process staring with lower value batches first by removing chunks with proximity order less than the storage radius until the size falls below the capacity.

If the size is still over the capacity, the storage radius is increased, and the eviction process repeats again, this time with a higher proximity order criteria.

When the radius increases, the neighborhood actually splits into two. If there is an insufficient number of nodes OR the overlay addresses, after the radius increase, all end of falling into the same neighborhood, the other neighborhood will have no nodes in it and this can cause loss of data for previously stored and newly uploaded chunks.

In the diagram below, imagine the case all nodes in neighborhood 7 share one higher order of proximity, so they all end up in neighborhood 9 after the radius is increased, leaving 4 without a single node.

0ZXSz

Task

  1. Before increasing the storage radius, the node will first check that the two neighborhoods after splitting the current one will have at least have one node. If not, then the radius increase will be skipped.
  2. In the case that there isn't sufficient number of peers, the pullsync worker will be paused and the pushsync will reject new chunks that it stores
  3. The pullsync and pushsyns protocols, if paused, will monitor topology changes and remain paused until the neighborhood split problem is resolved.
Lenguaje dominante
Go
Estrellas
1.5k
Forks
390
Merge medio
3 d 2 h
PR fusionados (30 d)
17

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ethersphere/bee

Todos los issues de ethersphere/bee

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.