Model SOCK_OPS flow lifetime independently of classify execution

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp
Área
networking, testing-qa

Línea de trabajo

Start from the simulated SOCK_OPS APIs, where flow ID creation and the synchronous WFP classify call happen in one operation, and from the flowDeleteFn path for associated contexts. Split creation, classification for an existing flow ID, and deletion into separate operations, keeping the synchronous helpers as wrappers. Done means IPv4 and IPv6 tests delete a flow before, during, and after classification, with exactly one flowDeleteFn callback per associated context.

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

Descripción

Problem

The simulated SOCK_OPS APIs create a flow ID and synchronously invoke the WFP classify callback in one operation. The caller does not regain control until classification completes, so a test cannot publish the simulated flow as live and delete that same flow while its established callback is running.

This prevents usersim from faithfully modeling independent WFP flow creation, classification, and deletion, and leaves the original SOCK_OPS association/program-invocation race difficult to regression-test without test-only synchronization inside the program callback.

Originating review: https://github.com/microsoft/ebpf-for-windows/pull/5623#discussion_r4450724952

Desired behavior

Represent a simulated network flow separately from an optional WFP flow-context association. Tests should be able to:

  1. Create a flow and receive its flow ID.
  2. Invoke classification for that existing flow ID.
  3. Delete the flow before, during, or after classification.

The existing synchronous helpers can remain as compatibility wrappers over the split operations.

Acceptance criteria

  • IPv4 and IPv6 SOCK_OPS flows can be created before classification begins.
  • Classification accepts an existing flow ID rather than always allocating one internally.
  • Flow deletion is safe before association, during classification, and after association.
  • An associated context receives exactly one flowDeleteFn callback.
  • Existing usersim callers retain compatible behavior.
  • Tests cover the three deletion timings for both address families.
Lenguaje dominante
C++
Estrellas
112
Forks
36
Merge medio
8 d 10 h
PR fusionados (30 d)
6

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 microsoft/usersim

Todos los issues de microsoft/usersim

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.