From tests conducted by @ersonp it's evident that the connection between two dmsg clients is fully mediated by the dmsg server and is not maintained in the absence of the connection to a dmsg server.
Hence the dmsg server is an intermediary in this connection which is not currently accounted for. By specification, a route should not transit the same public key twice, however, the public key of the dmsg server is not accounted for in the transports. Dmsg servers do not directly or wittingly take part in transports, seemingly by design.
Hence it is crucial that any attempt to create a route through the same dmsg server multiple times shall be thwarted by some means. Yet other important implications also arise.
Network Architecture - Public Visors & Dmsg Servers
Currently, dmsg servers are handling bandwidth for dmsg transports. The issue arises from the lack of recognition of the dmsg server in the transport entry. The fact is, as well, dmsg servers are not run from the visor and so do not connect to the same services such as transport discovery.
It should be possible to implement so that a visor may run a dmsg server with the same key. If this were possible, it would make sense to upgrade the dmsg servers on the production deployment to run a public visor with dmsg server. That would effectively mitigate the issue essentially by replacing dmsg transports with stcpr transports established by the public auto-connect. These transports would correctly account for the dmsg server as the other end of the transport and intermediary in multihop routes.
It is inevitable with the current setup that multi hop dmsg route traffic may overload dmsg servers with very little bandwidth because packets may transit the same server multiple times.
Dmsg Parallel Connection Optimization
Currently, there are no fine-grained controls for which dmsg servers are connected to by a client other than setting the minimum dmsg sessions. Configuring a dmsg client to use a specific dmsg server is not implemented for regular dmsg clients as it is for the visor with the dmsghttp-config.json. Even knowing which server is currently in use is not easily determined except in an attempt to connect to that client.
In the instance that dmsg clients are connected to more than one dmsg server by default, it should either be possible to take advantage of both the possible paths at once or a better fallback behavior on inability to connect should be established so that an attempt is made to connect to the other client via another dmsg server.
Dmsg Servers -to- Server Connection to Overcome Scaling Limitations
In a technical sense it is clear that not every dmsg client and not every visor may connect to every other over dmsg currently. This is due to the fact that every visor would need to be connected to every other visor via the same dmsg server. The scaling limit was increased somewhat by the visor connecting to 2 dmsg serves by default, however, it is currently the case that if both dmsg servers you are connected to have no available sessions, other clients will no longer be able to connect to your client that can't connect to at least one of the same dmsg servers.
It would make sense in light of this, to have dmsg servers connect to each other and via that connection, to be able to connect clients which are connected to different dmsg servers thereby overcoming the aforementioned scaling limitation.
Dmsg Servers need to help a local deployment - IP based reserved sessions
A dmsg server is basically a public server. While it benefits the network, there is no current mechanism by which running a dmsg server may specifically benefit the operator without the handicapping lack of interoperability of running one's own dmsg discovery in addition to that.
Hence, I suggest the ability to have an ip-based whitelist of clients which connect to a dmsg server. This would allow for running a dmsg server publicly with very few or no public sessions which would help local clients connect to each other - and possibly facilitate the connection to clients which are connected to other dmsg servers externally.
From tests conducted by @ersonp it's evident that the connection between two dmsg clients is fully mediated by the dmsg server and is not maintained in the absence of the connection to a dmsg server.
Hence the dmsg server is an intermediary in this connection which is not currently accounted for. By specification, a route should not transit the same public key twice, however, the public key of the dmsg server is not accounted for in the transports. Dmsg servers do not directly or wittingly take part in transports, seemingly by design.
Hence it is crucial that any attempt to create a route through the same dmsg server multiple times shall be thwarted by some means. Yet other important implications also arise.
Network Architecture - Public Visors & Dmsg Servers
Currently, dmsg servers are handling bandwidth for dmsg transports. The issue arises from the lack of recognition of the dmsg server in the transport entry. The fact is, as well, dmsg servers are not run from the visor and so do not connect to the same services such as transport discovery.
It should be possible to implement so that a visor may run a dmsg server with the same key. If this were possible, it would make sense to upgrade the dmsg servers on the production deployment to run a public visor with dmsg server. That would effectively mitigate the issue essentially by replacing dmsg transports with stcpr transports established by the public auto-connect. These transports would correctly account for the dmsg server as the other end of the transport and intermediary in multihop routes.
It is inevitable with the current setup that multi hop dmsg route traffic may overload dmsg servers with very little bandwidth because packets may transit the same server multiple times.
Dmsg Parallel Connection Optimization
Currently, there are no fine-grained controls for which dmsg servers are connected to by a client other than setting the minimum dmsg sessions. Configuring a dmsg client to use a specific dmsg server is not implemented for regular dmsg clients as it is for the visor with the
dmsghttp-config.json. Even knowing which server is currently in use is not easily determined except in an attempt to connect to that client.In the instance that dmsg clients are connected to more than one dmsg server by default, it should either be possible to take advantage of both the possible paths at once or a better fallback behavior on inability to connect should be established so that an attempt is made to connect to the other client via another dmsg server.
Dmsg Servers -to- Server Connection to Overcome Scaling Limitations
In a technical sense it is clear that not every dmsg client and not every visor may connect to every other over dmsg currently. This is due to the fact that every visor would need to be connected to every other visor via the same dmsg server. The scaling limit was increased somewhat by the visor connecting to 2 dmsg serves by default, however, it is currently the case that if both dmsg servers you are connected to have no available sessions, other clients will no longer be able to connect to your client that can't connect to at least one of the same dmsg servers.
It would make sense in light of this, to have dmsg servers connect to each other and via that connection, to be able to connect clients which are connected to different dmsg servers thereby overcoming the aforementioned scaling limitation.
Dmsg Servers need to help a local deployment - IP based reserved sessions
A dmsg server is basically a public server. While it benefits the network, there is no current mechanism by which running a dmsg server may specifically benefit the operator without the handicapping lack of interoperability of running one's own dmsg discovery in addition to that.
Hence, I suggest the ability to have an ip-based whitelist of clients which connect to a dmsg server. This would allow for running a dmsg server publicly with very few or no public sessions which would help local clients connect to each other - and possibly facilitate the connection to clients which are connected to other dmsg servers externally.