Closed speedpidi closed 4 years ago
Hi Peter,
I try to verify if my host is running so i get address from ZyanComponentHost property DiscoverableUrl
I'm considering marking this property as obsolete in the upcoming version.
Looks like I don't have much time (and need) to implement a working service discovery. And I don't know detect which of the network interfaces should be selected to represent the externally-discoverable URL of the service. So it's better to just drop the property to avoid confusion.
I get bullshit from this prop cause you bind protocol to the ip address 0.0.0.0.
What exactly do you get from this property? Something like "tcp://0.0.0.0:123/MyServerName"? What are you expecting to get from this property?
Or perhaps you need something other than a discoverable URL, in order to check if the server is running? Please clarify your requirements.
Regards, Alex
Hi Alex,
What exactly do you get from this property? Something like "tcp://0.0.0.0:123/MyServerName"?
You are right.
What are you expecting to get from this property? The full DiscoverableUrl which i can use to make a service discovery request. Something like tcp://RealIp/MyServerName
i use the functionality of Service Discovery in a project. Zyan is really nice cause its simple to make a Server Application which has high availability functions. This is enterprice level.
Yes i know the problems with DiscoveryClient. I enhanced the Client cause your Version only sends UDP Pakets on the first network interface UDPClient class gets from system. The version i use the DiscoveryClient does a full Discovery request on all nics which are available on the system. At this place maybe we can enhance zyan.
Regards, Peter
Hi Peter,
Something like "tcp://0.0.0.0:123/MyServerName"?
We can try to improve heuristics for building the discoverable URL property. Skipping 0.0.0.0 and 127.0.0.1 addresses looks reasonable.
i use the functionality of Service Discovery in a project. Zyan is really nice cause its simple to make a Server Application which has high availability functions. This is enterprice level.
I'm surprised :)
I had problems setting up UDP-based service discovery in my local network, and I finally gave up on it. My plan was to remove this feature because I can't use it myself and can't assist anyone in setting it up.
Yes i know the problems with DiscoveryClient. I enhanced the Client cause your Version only sends UDP Pakets on the first network interface UDPClient class gets from system. The version i use the DiscoveryClient does a full Discovery request on all nics which are available on the system. At this place maybe we can enhance zyan.
Would you mind creating a pull request for your service discovery client? It would be much better than just removing it from the library like I planned.
Hi Alex,
Pull request created.
Regards, Peter
Great! Thanks Peter 👍
Hi Peter, please build the latest version from sources. Let me know if everything is ok, so I can update the Nuget package.
Hi Alex,
everything works as expected.
Regards, Peter
Great! Thanks Peter.
You added support for Binding the Protocol to a IpAddress.
I use the Protocol without Binding to Ip Address. This Constructor
public TcpCustomServerProtocolSetup(int tcpPort, IAuthenticationProvider authProvider, bool encryption)
I try to verify if my host is running so i get address from ZyanComponentHost property DiscoverableUrl
I get bullshit from this prop cause you bind protocol to the ip address 0.0.0.0. Its the address from the local var in TcpCustomServerProtocolSetup.
For me this works TcpCustomServerProtocolSetup Method Create Channel
if (IpAddress != "0.0.0.0") { _channelSettings["bindTo"] = _ipAddress; }
Maybe you have a better solution, but i think we have a bug here.