-
Notifications
You must be signed in to change notification settings - Fork 173
Add WebSocket transport support #781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: GautamBytes <[email protected]>
Signed-off-by: GautamBytes <[email protected]>
cc @seetadev |
@GautamBytes : Thanks Gautam for submitting the PR. Appreciate your initiative and efforts. Please resolve the CI/CD issues. CCing @sumanjeet0012, @guha-rahul and @lla-dane for their feedback and pointers too. This module will be needed by a number of projects. Lets productionize it well. |
Signed-off-by: GautamBytes <[email protected]>
raise ValueError(f"No host protocol found in {maddr}") | ||
|
||
port = int(maddr.value_for_protocol("tcp")) | ||
uri = f"ws://{host}:{port}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we leaving support for ipv6 for later on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the catch!
I'll update the dial method to properly enclose IPv6 hosts in brackets.
…libp2p into add-ws-transport
@seetadev , @guha-rahul , i am trying to fix this failing workflows but facing difficulty . Its because of my test_js_ws_ping.py file not passing , error logs shows -
would really appreciate if someone can tell how to fix this! |
@GautamBytes : Thank you so much for taking the initiative to work on fixing the failing workflows. Your effort on test_js_ws_ping.py is really appreciated. The SwarmException error you’re seeing usually means that the WebSocket connection between the Python host and the JS peer isn’t being established — this could be due to a mismatch in multiaddr protocols, peer discovery issues, or the JS node not being ready when the test starts. @acul71, @guha-rahul , @varun-r-mallya — can you jump in to help debug this WebSocket issue with ? Maybe we can review the interop/test_js_ws_ping.py setup together and check: If the JS node is properly launched and listening on the expected /ws multiaddr. Whether dial_peer is using the correct transport and address. If any recent changes in the libp2p handshake or transport modules might have caused regressions. @GautamBytes, you might also try: Running the JS ping test manually with verbose logs (DEBUG=libp2p* pytest -s tests/interop/test_js_ws_ping.py) to see detailed handshake failures. Verifying that the JS node and Python host share the same set of supported protocols and transports. Testing if basic_host.connect(peer_info) works when you manually start a JS libp2p node with WebSocket enabled. Let’s collaborate and get this test passing soon. |
@GautamBytes @seetadev Work in progress....... |
…Add transport_registry.py for centralized transport management - Integrate WebSocket transport with new registry - Add comprehensive test suite for transport registry - Include WebSocket examples and demos - Update transport initialization and swarm integration
@GautamBytes can you give me access to push to your fork ? |
@GautamBytes : Hi Gautam. @acul71 is our amazing Py-libp2p developer, key maintainer to py-multiaddr, py-cid and core py-libp2p modules. Kindly give him push access so that he can collaborate with you on taking web socket to a production stage. Appreciate your efforts and initiative. |
@acul71 : Great, thanks Luca. Appreciate your initiative and support. I have asked Gautam to share access with you soon. He might be unavailable because of his engineering exams this week. Will be available soon in a day or two. |
@acul71 , i have invited u as collaborator , can u check the mail and confirm once? |
@acul71 : Can you confirm with @GautamBytes ? He did share an invite today. |
- Fix INotifee interface compliance in WebSocket demo - Fix handler function signatures to be async (THandler compatibility) - Fix is_closed method usage with proper type checking - Fix pytest.raises multiple exception type issue - Fix line length violations (E501) across multiple files - Add debugging logging to Noise security module for troubleshooting - Update WebSocket transport examples and tests - Improve transport registry error handling
Python WebSocket Implementation — Status & DiscussionDiscussion Links:
📌 OverviewOur current WebSocket implementation provides a robust foundation with comprehensive support for ✅ Key Strengths
❌ Primary Gap
📂 Recent Changes
🐛 Known Issues1. Failing Test
2. Missing
|
@seetadev @GautamBytes @GautamBytes what do you think of last changes see #781 (comment) Proposal: Implement missing |
@acul71 : Thanks for the clarification — that makes perfect sense regarding the current interop utility not being a proper test. I agree that while it’s been useful for quick verification, a more structured interop testing approach will be important going forward, especially if we want repeatable results and alignment with spec requirements. I’m aligned with your and Gautam's proposal to implement the missing WSS protocol first so we’re fully specs-compliant. This will give us a solid baseline for any future interoperability efforts. Once WSS is in place, we can revisit the interop testing framework and decide how to best structure it for automation while still keeping the ability to run quick “at home” checks for early feedback. I also reviewed your latest changes in the PR— the direction looks good, and I appreciate how you’re keeping both compliance and developer workflow in mind. Let’s proceed with WSS first, then use the local interop runs to validate, and afterward we can design the formal interop testing structure without blocking progress on the transport work. Excited to see this come together — with WSS and structured interop testing in place, py-libp2p’s transport story will be much stronger. |
Waiting for @GautamBytes feedback, I can help complete this PR |
Closes #585
This pull request introduces WebSocket transport support to
py-libp2p
, enabling interoperability with other major libp2p implementations likejs-libp2p
andgo-libp2p
that rely on/ws
multiaddrs.The implementation adds a new
libp2p.transport.websocket
module containing the necessary components to dial and listen on WebSocket connections, integrating seamlessly with the existingTransportUpgrader
andSwarm
.Key Features
WebsocketTransport
andWebsocketListener
: Implements the coreITransport
andIListener
interfaces for handling the WebSocket connection lifecycle./ws
Multiaddr Handling: Correctly parses/ip4/.../tcp/.../ws
multiaddrs for both dialing and listening. The listener also advertises the correct public/ws
address.trio-websocket
Integration: Usestrio-websocket
for native, non-blocking I/O within thepy-libp2p
trio
runtime.test_js_ws_ping.py
) that successfully establishes a connection and runs the/ipfs/ping/1.0.0
protocol with a livejs-libp2p
node, confirming bi-directional communication.TransportUpgrader
, allowing security protocols (e.g.,noise
) and stream multiplexers (e.g.,mplex
) to be layered on top.Scope
/ws
) transport./wss
) is deferred for future work as discussed in the issue. The transport will raise aNotImplementedError
if a/wss
address is provided.