You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
Feature description
Currently
dmsg.Tranport
s are identified by anuint16
value commonly referred to as the Transport ID. On top of this, we also have ports (also represented by anuint16
value) that is also used for identifyingdmsg.Transport
s.Additional context
Originally, Brandon wanted
dmsg
to have no ports, and we just basically create connections betweendmsg.Client
s. 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 withuint16
).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.The text was updated successfully, but these errors were encountered: