Skip to content

Conversation

xDimon
Copy link

@xDimon xDimon commented Oct 15, 2025

Summary

This PR introduces the x-shadow feature, which allows building Litep2p compatible with the Shadow network simulator.
When this feature is enabled, outgoing socket binding is disabled to prevent address collisions that occur under Shadow, which otherwise lead to AddrInUse errors when connecting to remote peers.

Changes

  • Added a new Cargo feature: x-shadow.
  • Disabled explicit binding of outgoing sockets when the feature is active.
  • djusted connection logic to comply with Shadow environment constraints.
  • Updated build configuration and conditional compilation accordingly.

Motivation

Under the Shadow simulator, each node runs in an isolated process namespace but shares the same IP address space.
Explicitly binding outgoing sockets may cause multiple nodes to use the same source address, resulting in EADDRINUSE collisions.
The x-shadow feature resolves this by skipping the bind step for outgoing connections, ensuring stable network behavior in simulation.

Compatibility

  • Activated via Cargo feature flag: --features x-shadow.
  • Has no effect on normal (non-Shadow) builds or runtime behavior.
  • Safe to merge — default build remains unchanged.

Testing

  1. Build with --features x-shadow.
  2. Run the binary under Shadow simulation.
  3. Verify that connections between peers establish successfully.
  4. Ensure no AddrInUse errors occur during parallel outgoing connections.
  5. Confirm clean shutdown and resource release after simulation.

Signed-off-by: Dmitriy Khaustov aka xDimon <[email protected]>
@xDimon xDimon changed the title fix: reuseaddr error under shadow Add x-shadow feature for Shadow simulation compatibility Oct 15, 2025
@dmitry-markin
Copy link
Collaborator

Hi @xDimon and thanks for contributing! The issue looks to me as networking configuration problem and not as the code limitation. If the processes under Shadow share the same address space (do you mean local IP?), the nodes must be configured to listen on different ports or other bad things will happen. Reusing the same local listen port the process is already listening on should not be the problem then.

Does this make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants