-
Notifications
You must be signed in to change notification settings - Fork 2
[M2] Identify 'dmsg.Transport' via remote and local pk:port pair. #36
Description
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.