Internal (app to app or machine to machine) UDP Communication

Hello!

The article about UDP services is a tad vague on whether or not the caveats are for ingress-type UDP communication, or for internal-only UDP communication.

Does internal-only UDP communication have the same caveats as the ingress-type UDP communication?

Hey! Which article are you referring to?

What are you hoping to do?

Hello!

I am referring to this article.

Basically, I have an orchestration engine deployment that requires no exposure to public interfaces. The primary executable calls the machines API to start up worker nodes, and those worker nodes need to communicate over UDP.

My netcat testing makes it clear that I need to bind to the secondary eth0, and that a UDP service must be declared in the fly config (which is weird because that is not the case with internal only TCP communication).

If I netcat from one of the machines to the primary app machine (using the 172.X.X.X internal address of the secondary eth0 of the destination), then it seems to work. However, making the same exact connection from one of the created machines to another does not appear to work, even if I set up a UDP service on the machine’s config.

I’m just wondering if there is an easier way to get the internal-only UDP communication working properly, or if 6PN addresses will soon support UDP communication.

Anything else I can add here?

Basically, I have a platform that internally communicates via quic over UDP, and I’d like to understand how to best allow the machines / apps to communicate with each other via UDP.

The article states that IPv6 addressing is not enabled at the kernel level for UDP, and all of the name resolution in fly resolves to IPv6? So, what is the best way to enable machine to machine UDP communication?

Hey! I just wanted to verify this. I just tested this using netcat, and UDP communication seems to work fine over 6PN.

Are you sure you are binding to the correct address and interface? Also, if I am not wrong, the UDP over IPv6 caveat does not apply to 6PN traffic.

1 Like

Cool! Is that machine-to-machine or app-to-app? Looks like you are just binding to Any? Not fly-global-services?

It is machine-to-machine. I am binding to any, but I assume binding to a 6PN subnet would work too. fly-global-services is meant for external services, and not machine-to-machine.

Also, quoting the private networking documentation,

Applications within the same organization are assigned special addresses (“6PN addresses”) tied to the organization. Those applications can talk to each other because of those 6PN addresses, but applications from other organizations can’t; the Fly platform won’t forward between different 6PN networks.

This connectivity is always available to applications; you don’t have to do anything special to get it.

I assume a similar setup will work for app-to-app as 6PN is tied to an organization and not an app.

Thanks!

Yeah, I understood the basics, but was led astray by the UDP documentation.

Another thing that won’t impact your code that you’ll need to know about is that we don’t currently support UDP over IPv6. The kernel forwarding code we run to make UDP work isn’t IPv6 aware. This is not OK, and we’re working on it, but it’s a limitation you’ll run into today.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.