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

Dmsg server optimization #33

Open
Darkren opened this issue Nov 10, 2020 · 2 comments
Open

Dmsg server optimization #33

Darkren opened this issue Nov 10, 2020 · 2 comments

Comments

@Darkren
Copy link
Contributor

Darkren commented Nov 10, 2020

While trying to make encryption optional I noticed one thing. What I'm going to write here is just a suggestion, and I might be totally wrong in my judgements, since I'm not that familiar with the code. This func here:

func (ss *ServerSession) serveStream(log logrus.FieldLogger, yStr *yamux.Stream) error {
. This func is called on each client->client packet if I get it right. What looks wrong to me in this func:

  1. We decrypt incoming package, perform all sorts of checks, encrypt and resend to the responding client. Would it hurt if we removed decryption/encryption part from here? This way during handshake server must transfer pub keys of clients to them each other. So client A encrypts, sends to the server, server sends to client B and client B decrypts. No ecnryption/decryption on the server side
  2. This func also verifies request, which includes verifiying the object signature. Do we really need the signature?
  3. We also calculate and compare request hash there. Is this needed too? If it's intended to check for data loss during transfer, I guess we shouldn't care about it as long as we use TCP

Probably we could also use something like SSL handshake. During handshake clients via server exchange their pub keys, generate 2 halves of a common symetric key, exchange it with PK-encrypted messages. After that point all the messaging may be encrypted with a single symmetric key which should be more performant. But not sure about this part, just a suggestion

@evanlinjin
Copy link
Contributor

This func is called on each client->client packet if I get it right.

I agree with everything you are saying except this statement. This function is only called to setup a stream. After the stream is set up, client->client communication (via the stream) is handled elsewhere.

@jdknives
Copy link
Member

@Darkren @evanlinjin in this case, it might make sense to make separate tickets for these proposals so we can tackle them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants