client/core: put the core together #120
Conversation
Adds websocket and database handling to the client core.
client/core/core.go
Outdated
| Logger dex.Logger | ||
| // Certs is a mapping of URL to filepaths of TLS Certificates for the server. | ||
| // This is intended for accomodating self-signed certificates, mostly for | ||
| // testing. |
There was a problem hiding this comment.
I expect self-signed TLS certs will be used in production for the server's RPC server. I suppose if the op wants to put up a website they would have certificates signed by a CA, but I wouldn't require that.
There was a problem hiding this comment.
server's RPC server
As in the server in server/comms? If the server doesn't use a CA, wouldn't they need to supply the certificate to every client? I've always assumed operators would get a domain name and use a CA in production, though I could see cases for small groups sharing a certificate for a private DEX.
There was a problem hiding this comment.
Right, certificate being provided to the client directly from the server operator, perhaps over a proper web server similar to how https://cspp.decred.org provides the pem cert for the actual CSPP server that listens on a different port. I don't think I would personally use a certificate signed by a CA for the server/comms.Server TLS RPC server. @jrick I'm using CSPP as an example, so perhaps you would have an opinion on whether it would make sense to use a CA signed certificate vs. self-signed as our services have done in the past, or even if it's possible or practical to use a CA for this.
There was a problem hiding this comment.
As one example, how would a CA be usable if you wanted to run a service with just an IP address.
| ReconnectSync: func() { | ||
| go c.handleReconnect(uri) | ||
| }, | ||
| Ctx: c.ctx, |
There was a problem hiding this comment.
We've gotten even more pushback about this, but we can continue to feel it out. No need to change for the unexported methods of Core I say.
There was a problem hiding this comment.
This pattern was in client/comms before, just hasn't been updated yet. For core.Core, I've used the runner.Runner interface.
This incorporates the db and comms package functionality into client core application. This PR should hopefully add some clarity to the client structure and enable concurrent work. @dnldd can add in order book handling. @JoeGruffins can implement an RPC server that uses the core. I'll start into authentication via web interface.
All the core does right now is list the available markets, but I think future work can be done independently in the following rough categories.
Eventually reconnect handling and match auditing too.