WebRTC exploration #396

ScottyPoi · 2022-12-16T01:11:30Z

WebRTC

PR to explore WebRTC use in Transport Layer

Hybrid Transport Service

Browser clients can now use a hybrid transport layer. This adds the capacity to connect directly to other browser-clients.

HybridTransportService
- this.webRTC = waku / webrtc tranpsort
- this.websocket = websocket transport

LibP2P / Waku

Browser clients may discover and set up connections using the WAKU protocol.
In the transport layer, a Waku-LightNode "subscribes" to its NodeId.
Messages pushed via Waku LightPush
- will be encoded and decoded using the client's NodeId
  - using @waku/interfaces Encoder/Decoder
- Nodes initiate connections by pushing a serialized discv5 PING packet to the peer's NodeId on the WAKU LightPush protocol
- Nodes subscribe to their own NodeId on LightPush protocol. Discv5 packets received this way are handled using transport.emit('packet', ...) just like those received any other way.

The PortalNetwork (PING/PONG) & Discv5 authentication packets (whoareyou, challenge, handshake) are exchanged using WAKU LightPush protocol.
WebRTC "handshake" packets (Offer/Answer/ICE) are exchanged using WAKU LightPush protocol.
All further messages are exchanged directly p2p (browser-to-browser) using WebRTC protocol.

The WAKU LightPush part was built using core @waku and @libp2p packages.
The WebRTC part was built from scratch using mozilla web api (https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API)

~~#### ENR~~
To advertise that a node is available for RTC connections, we add 1 byte to the ENR like ENR.set('rtc', 0x01). When sending a packet, we look for this bit in a peer's ENR, and then route the outgoing packet either to an rtc datachannel, or to the websocket proxy.

This part was removed as unnecessary
Embedding a webrtc tag in the ENR does not fully provide a way to route outgoing packets in all scenarios, so this part was dropped. The transport layer does not have access to the discv5 routing table, nor does it directly interact with ENR. This also failed to address scenarios where we have received a packet from a peer who's ENR is not yet known (1st PING).

Instead, the first time the hybrid transport handles an incoming packet from a new Multiaddr, it will Map that multiaddr to the type of transport (websocket vs. rtc) from which it was received. The hybrid "Send" function will check that map to determine how to send packets to that peer.

Without any RTC tag in the ENR...
When we PING an unknown node we will not yet know which transport it supports. In this case we will send the PING packet out along both transports. When a response is received, we then know which transport (websocket or webrtc) this peer supports.

The PING is sent first over WAKU to prioritize webrtc connections among hybrid Ultralight nodes.

Proxy / Multiaddr

The websocket proxy has been edited to listen for an event emitted from the connecting websocket to set the port number. This way, the udp port number can be selected during PortalNetwork.create(), instead of randomly by the Proxy.

CLI

Small edits made to fix some build issues. A CLI client can now connect to a browser-client running in normal mode.

Browser

Small layout changes. Header now displays address, nodeId, and ENR.
Routing table display will distinguish between RTC peers and websocket peers. RTC connected peers will be highlighted a different color, and have the RTC tag in the last column.

Issue: routing table view does not reliably display all peers
Two browsers may connect, but both may not appear in the display
They are connected. The issue is in the react components

To test

OPTIONAL From the root directory - npm run start-proxy
From the root directory - npm run start-browser-client
Open 2 browser pages to localhost:8080

If the PROXY is running
- clients should start and connect to external bootnodes, quickly building a routing table
If the PROXY is not running
- clients will fail to connect to external bootnodes

COPY ENR from one browser, and paste into connect to peer input on other page.

clients should connect over waku, perform discv5 handshake, perform webrtc handshake, and add eachother to their routing tables
You can now test using the Peer-Tools or Get-Block-By functions in the browser

acolytec3 · 2022-12-16T15:09:58Z

packages/browser-client/src/Components/Layout.tsx

@@ -43,8 +44,14 @@ export default function Layout() {

  const layoutVariant = useBreakpointValue({
    base: (
-      <Tabs height="100%" width={'100%'} index={state.tabIndex} onChange={handleTabsChange}>
-        <TabList height="5%" width="100%" justifyContent={'space-around'}>
+      <Tabs width={'100%'} index={state.tabIndex} onChange={handleTabsChange}>


Quick note that the simple chat tab is only visible in a mobile equivalent view.

I reverted all of the browser layout changes -- they were just a part of the process for me figuring things out

acolytec3

The biggest thing I'm wondering about is do we need to have the webrtc stuff embedded in the client and protocol? We're kind of breaking the modular transport concept by introducing all these special checks for webRTC in client and protocol and ideally all of that would be handled within the hybridTransport class. I've offered some ideas in my comments so let me know if there's a way I can further help.

acolytec3 · 2023-01-12T19:23:22Z

packages/portalnetwork/package.json

@@ -54,10 +52,17 @@
    "@ethereumjs/common": "^3.0.0",
    "@ethereumjs/tx": "^4.0.0",
    "@ethereumjs/util": "^8.0.0",
+    "@libp2p/bootstrap": "6.0.0",


Why are all these now devDependencies? Don't we need them installed in order to use the waku/libp2p stuff?

Moved them all up to dependencies. I'll admit that my grasp of the difference between dependencies and devDependencies is a bit fuzzy...

acolytec3 · 2023-01-12T19:27:48Z

.github/workflows/build-android-app.yml

@@ -25,7 +25,7 @@ jobs:
      with:
        node-version: 16
        cache: 'npm'
-
+    - run: npm i -g @mapbox/node-pre-gyp


What is the purpose of this build step? Is there some browser dependency that needs node-gyp or is this leftover from when you were using the older webtorrent tracker library?

acolytec3 · 2023-01-12T19:40:18Z

packages/portalnetwork/src/subprotocols/protocol.ts

+          toHexString(enr.get('rtc')!) === '0x01'
+        ) {
+          this.logger.extend('RTC')('Adding RTC conneection')
+          await this.client.discv5.sessionService.transport.connectWebRTC(enr.nodeId)


Would it be possible to move this whole thing down to the transport layer somehow? Ideally, the protocol layer stuff shouldn't need to worry about which transport layer we're using. Could you move the webRTC maps up from webRTC.ts to hybridTransport.ts and then use the multiaddr or nodeId passed into client.discv5.session.transport.send to figure out whether to go with webRTC or websocket->UDP?

Yes, in fact this was not necessary here at all, as it is happening in the transport itself now. Deleting these lines should not have an affect

acolytec3 · 2023-01-12T19:42:20Z

packages/portalnetwork/src/transports/hybridTranpsort.ts

+    this.webRTC.closeAll()
+  }
+
+  async send(to: Multiaddr, toId: string, packet: IPacket, rtc?: boolean) {


As noted in my other comment, instead of adding a new parameter to the transport interface for send here, can we just keep a Map<nodeId, webRTCcontactinfo> inside this class and determine whether to use webrtc or websockets here?

Yes, agreed. I tried several solutions to the "PING from unknown node" problem, and that rtc parameter was one of the clunkier ones. the webrtc transport does already keep a map of nodeId > RTCConnection.

ScottyPoi · 2023-01-13T08:44:03Z

.github/workflows/build-android-app.yml

+    - run: npm i -g @mapbox/node-pre-gyp
    - run: npm i


I think this can be removed. I mentioned this at some point, but a lot of older webrtc npm packages (simple-peer, etc.) use a package called wrtc, which will not build without this node-pre-gyp thing installed in the system. I'm pretty sure I've removed anything that referenced that package, though.

Confirmed. deleted those changes and the build works fine.

Transport

ScottyPoi · 2023-01-23T00:45:43Z

@acolytec3

The cli-devnet-integration test is replacing the previous integration suite. it can probably be expanded, but I think it is sufficient.

My own testing hasn't exposed any issues with the webrtc transports, so I'd be confident merging this with your approval.

acolytec3 · 2023-01-23T14:37:56Z

@acolytec3

The cli-devnet-integration test is replacing the previous integration suite. it can probably be expanded, but I think it is sufficient.

My own testing hasn't exposed any issues with the webrtc transports, so I'd be confident merging this with your approval.

Fine by me. I added node-pre-gyp to the cli dependencies since npm i doesn't work locally otherwise. It's going to be a hard requirement for anyone trying to build the cli version of the client going forward.

ScottyPoi · 2023-01-23T22:58:39Z

Fine by me. I added node-pre-gyp to the cli dependencies since npm i doesn't work locally otherwise. It's going to be a hard requirement for anyone trying to build the cli version of the client going forward.

does that work??

i found that i needed node-pre-gyp installed globally, before doing npm i. This is certainly not ideal, i know. I tried hard to find a webrtc package that did not have wrtc somewhere in the dependency tree, but alas.

It may just look like me building it from scratch in typescript. maybe i'll get famous on npm

ScottyPoi

Ah, I should have explained --

the cli npm run test:integration triggers the previous integration test adapted for the nodejs client.
While this test does pass locally, it never worked (wouldn't actually run) in the CI checks.

The other model that was already in place, the "devnet-cli-test", has always worked, and I think as it is now, it does cover the same ground as the old integration tests

ScottyPoi · 2023-02-02T23:42:42Z

@acolytec3
any more thoughts on this?
i removed the webrtc stuff from CLI, and all of the wrtc / node-pre-gyp stuff along with it.

acolytec3

Awesome work! We still need to work on the race conditions in the contentWriter but this can be addressed later.

acolytec3 reviewed Dec 16, 2022

View reviewed changes

acolytec3 reviewed Jan 12, 2023

View reviewed changes

ScottyPoi commented Jan 13, 2023

View reviewed changes

ScottyPoi added 27 commits January 22, 2023 17:12

Diagram of Browser with RTC

e2f6400

proxy: choose port 9009 - 9999

6615c14

portalnetwork: add p2pt dependency

5f5c714

portalnetwork: create RTCPeerManager

bf10e71

portalnetwork: create simpleRTC.ts Transport Layer

20feb76

portalnetwork: switch WebSocket Transport for SimpleRTC Transport

34c45d9

portalnetwork: update protocol class to deal with RTC peers

c5b1094

browser-client: update portalClient.ts to use SimpleRTC

48a0222

Transport

browser-client: update RoutingTableView to display RTC peers

7d29e8e

browser-client: add Tab for RTC interface

a4d5a0c

fix github actions...maybe

6ed5e6e

totally fix github actions

52674cb

Fixing Github actions one last time

509b136

portalnetwork: separate webrtc and websocket code

1728818

Automatically Ping new webrtc peer on completion of handshake

cd958c9

Update Browser Components

3d2eceb

remove unused

a6a2fd3

create HybridTransportService

fd66159

update client for hybrid transport

5c3342a

update browser client to use hybrid tranpsort

acbb1a3

update Proxy to use selected port number

485e19b

fix CLI build issue

2a6a931

fix multiaddr and delete comments

10656ee

commit package-lock.json

013a01a

update WebRTC Diagrams

2e123ef

add diagram for waku/webrtc protocol

1782159

remove node-pre-gyp from CI jobs

2fd2f35

ScottyPoi added 6 commits January 22, 2023 17:15

delete / move files

e1ceb41

move integration test command to CLI test runner

7b762e6

fix client ip bug

17cd93e

add tape to npm scripts

431c502

fix node version in github actions

622657e

fix for CI test

2891400

ScottyPoi force-pushed the webrtc branch from 3859fff to 2891400 Compare January 23, 2023 00:15

remove broken integration test

f165b32

ScottyPoi force-pushed the webrtc branch from 3ccf407 to f165b32 Compare January 23, 2023 00:34

Add node-pre-gyp to cli

79d5780

acolytec3 added 2 commits January 23, 2023 09:40

add CLI integration test to CI

15b48e5

Add start of integration test back to portalnetwork

4d02ba3

ScottyPoi commented Jan 23, 2023

View reviewed changes

acolytec3 and others added 3 commits January 23, 2023 20:44

change integration tests

2c95d80

portalnetwork: implement rest of integration tests

3ed2aa5

CLI: remove webrtc / waku changes

246fa3f

ScottyPoi force-pushed the webrtc branch from 5a980ac to 246fa3f Compare January 27, 2023 08:09

ScottyPoi added 3 commits January 27, 2023 14:36

CLI: fix github devnet test run ip

5fbf217

remove unused changes

656f880

update package-lock

44ab6af

acolytec3 added 2 commits February 3, 2023 09:28

clean up tests and testdata

0d1d9ed

Partially fix integration test race conditions

6da3610

acolytec3 approved these changes Feb 3, 2023

View reviewed changes

acolytec3 merged commit 06d6910 into master Feb 3, 2023

acolytec3 deleted the webrtc branch July 19, 2023 11:51

acolytec3 mentioned this pull request Oct 12, 2023

Accessing the Portal Network from a browser ethereum/portal-network-specs#232

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebRTC exploration #396

WebRTC exploration #396

ScottyPoi commented Dec 16, 2022 •

edited

Loading

acolytec3 Dec 16, 2022

ScottyPoi Jan 13, 2023

acolytec3 left a comment

acolytec3 Jan 12, 2023

ScottyPoi Jan 13, 2023

acolytec3 Jan 12, 2023

acolytec3 Jan 12, 2023

ScottyPoi Jan 13, 2023

acolytec3 Jan 12, 2023

ScottyPoi Jan 13, 2023

ScottyPoi Jan 13, 2023

ScottyPoi Jan 13, 2023

ScottyPoi commented Jan 23, 2023

acolytec3 commented Jan 23, 2023

ScottyPoi commented Jan 23, 2023

ScottyPoi left a comment

ScottyPoi commented Feb 2, 2023

acolytec3 left a comment

WebRTC exploration #396

WebRTC exploration #396

Conversation

ScottyPoi commented Dec 16, 2022 • edited Loading

WebRTC

PR to explore WebRTC use in Transport Layer

Hybrid Transport Service

LibP2P / Waku

Proxy / Multiaddr

CLI

Browser

To test

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acolytec3 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ScottyPoi commented Jan 23, 2023

acolytec3 commented Jan 23, 2023

ScottyPoi commented Jan 23, 2023

ScottyPoi left a comment

Choose a reason for hiding this comment

ScottyPoi commented Feb 2, 2023

acolytec3 left a comment

Choose a reason for hiding this comment

ScottyPoi commented Dec 16, 2022 •

edited

Loading