Need remote address info from perspective of receiver

[stdarg]

I like the generateId() in the managers, but the cluster processes need to contact each other asynchronously. In the case of UDP, where broadcast packets can route across sub-nets and for TCP, NATs cause a problem. Relying on the sender to self-identify doesn't work.

When NATs are in use, the only way to contact the sender is to have the IP and port from the received network request. For UDP, port forwarding would have to be in-place, but let's assume that's the case.

On the service data, it would be great to have an rinfo object with port and ip properties.

[Schoonology]

I'll do just that. The contents of the object will be url.format compatible: hostname and port at the least. Jury's out on the name of the property, it may be url to match most other frameworks, etc.

[Schoonology]

What luck - TCP and UDP have the same rinfo format, with TCP sockets as address(). We'll run with rinfo and that format instead.

[stdarg]

Thank you, Michael!

[nevercast]

Is this completed?

[Schoonology]

@nevercast - I'm not sure we ever got that far at the time, but it's never too late. Is this something you need?

[nevercast]

I didn't fully understand the intent on this issue but it sounded like the remote information of another Master is not available to Masters that join to it. (Remote address information is not exposed).

That would be good information to pass around if there was to be a connection beyond just discovering services but utilizing them too.

Could you clarify the issue if it's not too much trouble?

[Schoonology]

That was precisely the issue. The Manager instances don't share that rinfo data from incoming Services, only the original data provided when the Service is created.

This has been suitable for existing use cases, which are generally in-datacenter, but will be insufficient for cross-datacenter, NAT'ed applications.

[nevercast]

Ah yes. Then this does apply to me. I wish to use this across multiple VPS providers.

Are there security concerns with using this service when on a public facing network?

[Schoonology]

That depends on the use case and the Manager involved. In short, I would either provide authentication at the Manager level (so each Registry would authenticate with the Manager to broadcast updates), or I would ensure sufficient authentication exists between Services.

Where possible, however, I would recommend against making Managers publicly available. You could filter the traffic at a firewall, or use a feature like DigitalOcean's Private Networking and only bind the Manager to the private NIC.

On Tue, Jun 30, 2015 at 12:12 AM, Josh Lloyd notifications@github.com wrote:

Ah yes. Then this does apply to me. I wish to use this across multiple VPS providers.

Are there security concerns with using this service when on a public facing network?

— Reply to this email directly or view it on GitHub https://github.com/Schoonology/discovery/issues/1#issuecomment-117029730 .

[nevercast]

Thank you for your reply,

Could the HTTP Manager implementation utilize Client/Server certificates? That is the method I'm using for the actual services.

[Schoonology]

What would the certificates provide?

Either way, @stdarg and I were thinking of using relatively transport-agnostic properties like https://nodejs.org/api/net.html#net_socket_remoteaddress to provide some level of confidence around reachability. While this can be thwarted in similar ways to sender-identified addresses, the likelihood of reachability is greater.

To me, preferred to both of these is to either solve reachability at the architectural level or send along an application-specific address like a CNAME using the synchronized data in lieu of this automated addressing.