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

[M2] Identify 'dmsg.Transport' via remote and local pk:port pair. #36

Open
evanlinjin opened this issue Aug 22, 2019 · 0 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@evanlinjin
Copy link

Feature description

Currently dmsg.Tranports are identified by an uint16 value commonly referred to as the Transport ID. On top of this, we also have ports (also represented by an uint16 value) that is also used for identifying dmsg.Transports.

Additional context

Originally, Brandon wanted dmsg to have no ports, and we just basically create connections betweendmsg.Clients. This required us to differentiate the connections from each other, so we know which message is going to where. Hence, Brandon suggested we use a Transport ID (represented with uint16).

However, now Brandon wanted to introduce ports. If we had known we wanted ports earlier, we could just have identified the connections via the combination of the local/remote pubKey/port pair (like a TCP connection).

But we didn't know this, so now dmsg is also a mess, with both the ideas of Transport IDs and ports.

@evanlinjin evanlinjin added the enhancement New feature or request label Aug 22, 2019
@evanlinjin evanlinjin changed the title Identify "dmsg.Transport" via remote and local pk:port pair. [M2] Identify "dmsg.Transport" via remote and local pk:port pair. Aug 26, 2019
@evanlinjin evanlinjin changed the title [M2] Identify "dmsg.Transport" via remote and local pk:port pair. [M2] Identify 'dmsg.Transport' via remote and local pk:port pair. Aug 26, 2019
@evanlinjin evanlinjin self-assigned this Aug 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant