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
We are currently testing a setup that builds on the token-sdk services from the fabric-samples. The FSC nodes are running on a kubernetes cluster hosted by a cloud provider, and we are now testing the expansion of the setup to one spanning multiple clusters.
This creates some challenges with regards to the connectivity between the nodes. The pods that run the FSC nodes are not aware of their public IP address, and so they will announce their local ones (I believe via libp2p's identify protocol). FSC nodes on a different cluster will then be unable to reach them via these local addresses.
I identified one possible culprit, which is that in FSC, the p2p hosts are created using the libp2p.ForceReachabilityPublic() option. Is there a need or advantage of using this option?
We are still using v0.3.0, as this is the latest tagged release and the fabric sample also builds on this version. In this version it was not sufficient to remove the libp2p.ForceReachabilityPublic() option, so I assume some solution eg involving libp2p's AutoNAT would need to be built into FSC. Do you already have any plans that go in this direction? Or did you envision another solution for this?
For v0.3.0 there is an easy fix, which is to replace the following if-statement in the sendTo function
with if len(address) != 0 {, and thus to override the addresses in the peerstore with those from the core.yaml each time a message is sent. (The && strings.HasPrefix(address, "/ip4/") part is in conflict with the AddressToEndpoint function a few lines below, which expects IP addresses in the format ip:port.)
In the latest version of FSC, the block of code we use above is missing, so I assume this would not be your preferred way of solving this? :) I have also seen that there is a new routing config referenced in the core.yaml. I could not test it yet, as our code is not compatible with the latest FSC. Do you know whether updating to it would already fix the issue?
Thanks!
The text was updated successfully, but these errors were encountered:
Hi!
We are currently testing a setup that builds on the token-sdk services from the fabric-samples. The FSC nodes are running on a kubernetes cluster hosted by a cloud provider, and we are now testing the expansion of the setup to one spanning multiple clusters.
This creates some challenges with regards to the connectivity between the nodes. The pods that run the FSC nodes are not aware of their public IP address, and so they will announce their local ones (I believe via libp2p's identify protocol). FSC nodes on a different cluster will then be unable to reach them via these local addresses.
I identified one possible culprit, which is that in FSC, the p2p hosts are created using the
libp2p.ForceReachabilityPublic()
option. Is there a need or advantage of using this option?We are still using v0.3.0, as this is the latest tagged release and the fabric sample also builds on this version. In this version it was not sufficient to remove the
libp2p.ForceReachabilityPublic()
option, so I assume some solution eg involving libp2p's AutoNAT would need to be built into FSC. Do you already have any plans that go in this direction? Or did you envision another solution for this?For v0.3.0 there is an easy fix, which is to replace the following if-statement in the
sendTo
functionfabric-smart-client/platform/view/services/comm/p2p.go
Line 192 in 7e0f220
if len(address) != 0 {
, and thus to override the addresses in the peerstore with those from thecore.yaml
each time a message is sent. (The&& strings.HasPrefix(address, "/ip4/")
part is in conflict with theAddressToEndpoint
function a few lines below, which expects IP addresses in the formatip:port
.)In the latest version of FSC, the block of code we use above is missing, so I assume this would not be your preferred way of solving this? :) I have also seen that there is a new routing config referenced in the
core.yaml
. I could not test it yet, as our code is not compatible with the latest FSC. Do you know whether updating to it would already fix the issue?Thanks!
The text was updated successfully, but these errors were encountered: