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

Allow instantiation with existing ws #49

Open
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@adrianhopebailie
Copy link
Contributor

commented Dec 12, 2018

This change is required by interledgerjs/ilp-connector#476

It allows an AccountProvider in the connector to create new instances of the plugin from sockets that are created by a WS server running outside the plugin.

Show resolved Hide resolved src/index.ts Outdated

matdehaast and others added some commits Nov 29, 2018

feat: add option to pass raw socket into plugin
* added test coverage
* pass in raw socket to plugin

@adrianhopebailie adrianhopebailie force-pushed the feat/ws-constructor branch from 09d85e0 to 1aaed04 Jan 15, 2019

@@ -120,6 +123,58 @@ describe('BtpPlugin', function () {
})
})

describe('can pass in websocket connection', function () {

beforeEach(async function () {

This comment has been minimized.

Copy link
@sentientwaffle

sentientwaffle Jan 15, 2019

Contributor

The rest of this project is 2-space indented.

@@ -132,6 +132,9 @@ export interface IlpPluginBtpConstructorOptions {
port: number,
secret: string
},
raw?: {

This comment has been minimized.

Copy link
@sentientwaffle

sentientwaffle Jan 15, 2019

Contributor

Is there a reason for this extra layer of indirection?

Also, from the option alone it isn't clear whether the created plugin will act as a client or server. Maybe it should be server_socket (in the top-level options), or listener.socket.

This comment has been minimized.

Copy link
@adrianhopebailie

adrianhopebailie Jan 17, 2019

Author Contributor

Is there a reason for this extra layer of indirection?

Good suggestion. I think listener.socket makes the most sense.

Also, from the option alone it isn't clear whether the created plugin will act as a client or server.

The plugin is not going to act as a WS server because it is created around an existing ws socket so it's not listening for new connections.

BUT it will handle incoming auth messages (i.e. it's a "BTP server" in as much as the difference between a client and server is that one performs auth with the other even though they may actually be peers)

This is a general problem (I think) with the architecture of the plugin in that it mixes the transport (websockets) with the protocol (BTP).

I tried a more decoupled approach with ilp-transport, interested to hear what you think of that and if we could move to something similar with BTP: https://github.com/adrianhopebailie/ilp-transport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.