Model SOCK_OPS flow lifetime independently of classify execution

Aperta
  • Qualcosa non va?
#346 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
networking, testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
C++
Stelle
112
Fork
36
Merge medio
8g 10h
PR unite (30g)
6

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/usersim

Tutte le issue di microsoft/usersim

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.