I am currently working on a distributed quantum communication framework using SimulaQron and NetQASM as part of a research project on QKD integration. While my networking and backend communication layers are fully validated, I have encountered critical runtime and dependency blockers that prevent the generation of remote EPR pairs.
Environment Details
- Operating System: Ubuntu Linux
- Python Environment: 3.10 (Created as a "clean" environment specifically to resolve build failures observed under Python 3.12 regarding pkgutil.ImpImporter and numpy dependencies.)
- SimulaQron: 4.x
- NetQASM: 2.3.0
Detailed Error Analysis
-
Runtime EPR Generation Failures
The distributed backend successfully accepts connection requests, but the entanglement process fails consistently after the initial handshake.
Bob node Traceback: RuntimeError: TIMEOUT, no EPR generation received.
Alice Node Traceback: RuntimeError: Calling Stale Broker.
Log Findings: Backend synchronization is unstable; logs frequently report ConnectionRefusedError and Exhausted maximum attempts to connect to local/neighbour virtual node. These logs confirm that the backend nodes are struggling to maintain synchronization during the EPR generation phase.
-
NetQASM API Mismatches
Source code investigation suggests that the current NetQASM SDK version installed in my environment deviates significantly from the distributed examples I am attempting to implement. Specific recurring errors include:
Cannot instantiate abstract class: This occurs when attempting to initialize base connection classes.
Missing recv_epr and Missing create_epr: The methods referenced in standard documentation appear to be missing from my current SDK installation.
EPRSocket connectivity issues: The EPRSocket reports no open connection, even when backend sockets are verified to be active and listening.
-
Dependency Chain Breakdown
Efforts to resolve these issues by installing squidasm have revealed a broken dependency ecosystem:
Executing pip install squidasm==0.13.6 fails with the error: No matching distribution found: netsquid-netbuilder.
The entire dependency chain (SquidASM → NetSquid → netsquid-netbuilder → netsquid-magic) is inaccessible, suggesting that modern examples rely on a specific ecosystem configuration that is not currently compatible with my setup.
Experimental Validation Steps Taken
To rule out infrastructure issues, I have performed the following validations:
Connectivity: Bidirectional ping and VPN routing confirmed to be functional.
Ports: Firewall/routing issues were ruled out via nc -vz on both application and VNode ports.
Architecture: The target architecture-where Alice and Bob execute independent applications, each running its own QNodeOS and Virtual Node-has been traced. Remote procedure calls are being issued but fail specifically during the EPR synchronization phase.
Request for Guidance
I am currently blocked on these software stack compatibility issues, which prevents me from advancing to BB84 implementation and ETSI-compliant API integration. I would appreciate guidance on the following:
Version Matrix: What is the officially supported combination of SimulaQron, NetQASM, and the NetSquid ecosystem for distributed EPR generation?
SDK/API Usage: Are there updated distributed EPR generation examples that align with the current SDK methods, given that recv_epr and create_epr are missing?
Dependency Resolution: Is there a recommended procedure or specific virtual environment build path required to satisfy the squidasm/netsquid-netbuilder dependency chain?
Any documentation or recommended configuration matrices would be invaluable for resolving these blockers.
I am currently working on a distributed quantum communication framework using SimulaQron and NetQASM as part of a research project on QKD integration. While my networking and backend communication layers are fully validated, I have encountered critical runtime and dependency blockers that prevent the generation of remote EPR pairs.
Environment Details
Detailed Error Analysis
Runtime EPR Generation Failures
The distributed backend successfully accepts connection requests, but the entanglement process fails consistently after the initial handshake.
Bob node Traceback: RuntimeError: TIMEOUT, no EPR generation received.
Alice Node Traceback: RuntimeError: Calling Stale Broker.
Log Findings: Backend synchronization is unstable; logs frequently report ConnectionRefusedError and Exhausted maximum attempts to connect to local/neighbour virtual node. These logs confirm that the backend nodes are struggling to maintain synchronization during the EPR generation phase.
NetQASM API Mismatches
Source code investigation suggests that the current NetQASM SDK version installed in my environment deviates significantly from the distributed examples I am attempting to implement. Specific recurring errors include:
Cannot instantiate abstract class: This occurs when attempting to initialize base connection classes.
Missing recv_epr and Missing create_epr: The methods referenced in standard documentation appear to be missing from my current SDK installation.
EPRSocket connectivity issues: The EPRSocket reports no open connection, even when backend sockets are verified to be active and listening.
Dependency Chain Breakdown
Efforts to resolve these issues by installing squidasm have revealed a broken dependency ecosystem:
Executing pip install squidasm==0.13.6 fails with the error: No matching distribution found: netsquid-netbuilder.
The entire dependency chain (SquidASM → NetSquid → netsquid-netbuilder → netsquid-magic) is inaccessible, suggesting that modern examples rely on a specific ecosystem configuration that is not currently compatible with my setup.
Experimental Validation Steps Taken
To rule out infrastructure issues, I have performed the following validations:
Connectivity: Bidirectional ping and VPN routing confirmed to be functional.
Ports: Firewall/routing issues were ruled out via nc -vz on both application and VNode ports.
Architecture: The target architecture-where Alice and Bob execute independent applications, each running its own QNodeOS and Virtual Node-has been traced. Remote procedure calls are being issued but fail specifically during the EPR synchronization phase.
Request for Guidance
I am currently blocked on these software stack compatibility issues, which prevents me from advancing to BB84 implementation and ETSI-compliant API integration. I would appreciate guidance on the following:
Version Matrix: What is the officially supported combination of SimulaQron, NetQASM, and the NetSquid ecosystem for distributed EPR generation?
SDK/API Usage: Are there updated distributed EPR generation examples that align with the current SDK methods, given that recv_epr and create_epr are missing?
Dependency Resolution: Is there a recommended procedure or specific virtual environment build path required to satisfy the squidasm/netsquid-netbuilder dependency chain?
Any documentation or recommended configuration matrices would be invaluable for resolving these blockers.