Skip to content
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

experimental-websocket-port: option to accept websocket connections on additional port. #4685

Merged
merged 5 commits into from
Oct 22, 2021

Conversation

rustyrussell
Copy link
Contributor

@rustyrussell rustyrussell commented Jul 27, 2021

An implementation of lightning/bolts#891

(Updated to match spec, which now says you should advertize a new address type, not a feature).

Changelog-None: experimental features are not changlogged.

@rustyrussell rustyrussell added feature protocol These issues are protocol level issues that should be discussed on the protocol spec repo voodoo Suspect user, issue or code has ancient curse clightning_twit Tag to nudge @niftynei to post to @clightning_twit labels Jul 27, 2021
@rustyrussell rustyrussell added this to the v0.10.2 milestone Jul 27, 2021
Makefile Show resolved Hide resolved
@rustyrussell
Copy link
Contributor Author

Trivial rebase, and added Changelog-EXPERIMENTAL line.

@rustyrussell rustyrussell force-pushed the guilt/websockets branch 2 times, most recently from c896708 to 6422261 Compare August 27, 2021 04:48
@rustyrussell rustyrussell marked this pull request as draft August 30, 2021 03:25
@cdecker
Copy link
Member

cdecker commented Sep 6, 2021

Looking good, we could merge this as soon as it gets undrafted :-)

@cdecker cdecker removed this from the v0.10.2 milestone Sep 29, 2021
@rustyrussell rustyrussell changed the title experimental-websocket: option to accept websocket connections on lightning port. experimental-websocket-port: option to accept websocket connections on additional port. Oct 15, 2021
@rustyrussell rustyrussell marked this pull request as ready for review October 15, 2021 04:40
@rustyrussell rustyrussell force-pushed the guilt/websockets branch 3 times, most recently from 03e3137 to bff4a86 Compare October 18, 2021 00:13
@cdecker
Copy link
Member

cdecker commented Oct 18, 2021

Thanks, will review and merge into v0.10.2 if we have time.

@cdecker cdecker added this to the v0.10.2 milestone Oct 18, 2021
@cdecker
Copy link
Member

cdecker commented Oct 21, 2021

ACK bff4a86

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If the port is set, we spawn it (lightning_websocketd) on any
connection to that port.  That means websocketd is a per-peer daemon,
but it means every other daemon uses the connection normally (it's
just actually talking to websocketd instead of the client directly).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
WebSocket is a bit weird:
1. It starts like an HTTP connection, but they send special headers.
2. We reply with special headers, one of which involves SHA1 of one of theirs.
3. We are then in WebSocket mode, where each frame starts with a 2-20 byte
   header.

We relay data in a simplistic way: if either side sends something, we
read it and relay it synchronously.  That avoids any gratuitous
buffering.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@cdecker
Copy link
Member

cdecker commented Oct 21, 2021

Rebased on top of master

ACK 702d485

@cdecker cdecker merged commit ed6eaf9 into ElementsProject:master Oct 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clightning_twit Tag to nudge @niftynei to post to @clightning_twit feature protocol These issues are protocol level issues that should be discussed on the protocol spec repo voodoo Suspect user, issue or code has ancient curse
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants