UDP server not receiving messages

Questions / Help
1

I’ve been struggling with this issue for hours, hopefully someone can help.

I have a UDP server and TCP server just for health status, inside the live logs I do get logs that the server does get bind to the correct host and port according to the docs. In my case, I have it bind to fly-global-services:2000 for UDP and 0.0.0.0:3000 for TCP. When deploying and starting the server, it logs. I’ve tried using fly-global-service and 0.0.0.0 for the UDP port.

[info] HTTP Server listening on 0.0.0.0:3000
[info] Server listening on fly-global-services:2000

I test sending messages using Packet Sender using a fly shared IPv4 IP and the port (2000) but it doesn’t seem to receive nothing, on the TCP side, that does work, I am able to go to my domain and get back data. Do UDP services only work on dedicated IP’s or do shared IP’s also work?

For more context, below is some code:

I use node:dgram for UDP so bind code looks something like this

server.bind(port.port, UDP_HOST, () => {
    console.log(`Server listening on ${UDP_HOST}:${port.port}`);
    return logger.warn({
      success: true,
      message: `Server listening on ${UDP_HOST}:${port.port}`,
      status: 200,
    });
  });

TCP bind looks something like this (using http)

monitorServer.listen(3000, TCP_HOST, () => {
  console.log(`HTTP Server listening on ${TCP_HOST}:3000`);
  logger.warn({
    success: true,
    message: `HTTP Server listening on ${TCP_HOST}:3000`,
    status: 200,
  });
});

My fly.toml file looks like this

app = 'udp-server'
primary_region = 'lax'
processes = ['app']

[[services]]
protocol = 'udp'
internal_port = 2000

[[services.ports]]
port = 2000

[[services]]
protocol = 'tcp'
internal_port = 2000
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0

[[services.ports]]
port = 2000

[[vm]]
size = 'shared-cpu-1x'
2

Hi,

Ah, yes. I think you’ve identified the issue:

Do UDP services only work on dedicated IP’s or do shared IP’s also work?

You would need a dedicated IPv4.

For more about that, check out this part:

3

Hey, actually after this post I did try to launch a whole new instance and with only a dedicated IP, but that didn’t work either, everything in console pointed that everything was working but still was not receiving any data

4

Hey,

That’s strange :thinking:

You can also allocate a dedicated IPv4 to an existing app, but if you’ve made a new one that’s fine.

I notice in that particular fly.toml it lists port 2000 … but your app code has a HTTP server on port 3000. That shouldn’t affect the UDP but I guess you could try e.g using 3000 for the code and fly.toml for TCP and 2000 for the code and fly.toml for the UDP, just to rule out anything there.

The other thing could be the UDP_HOST … Should that be an IP rather than fly-global-services?

5

Hey so I gave up yesterday and deleted the instance I made but I re-deployed it today, following the changes you suggested, this is actually how I had the first time (followed this example https://github.com/fly-apps/udp-echo-/blob/main/fly.toml, today I’m not sure what the problem is anymore, now when going to the deployed URL, I get back nothing, it just loads, this was working yesterday.

When it comes to the UDP_HOST, I have tried with fly-global-services, 0.0.0.0 and the IP, but the IP just makes the server crash. I even tried 127.0.0.1.

I know the server works, it was on AWS working for about a year now, I had TCP on port 3000 and UDP on port 2000, and the way it would work was using 0.0.0.0 as the HOST, I want to migrate to fly but nothing seems to work correctly. I had the TCP part working on fly but for some reason, it doesn’t work anymore :smiling_face_with_tear:

My current fly.toml

app = 'udp-server'
primary_region = 'lax'
processes = ['app']

kill_signal = "SIGINT"
kill_timeout = 5

[experimental]
allowed_public_ports = []
auto_rollback = true

[[services]]
protocol = 'udp'
internal_port = 2000

[[services.ports]]
port = 2000

[[services]]
protocol = 'tcp'
internal_port = 3000
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0

[[services.ports]]
port = 2000

[[vm]]
size = 'shared-cpu-1x'
6

Ah … ok. Yep, comparing to the Fly demo app, the port can’t be the issue. As they expose port 5000 and use 5000 as the internal value for both TCP and UDP in the same app. So yes, you should be fine with using 2000 instead, as you have in that latest fly.toml.

The reason why I thought it previously wouldn’t was only because of this line which was using 3000 but the fly.toml was 2000:

monitorServer.listen(3000, TCP_HOST, () => {

Hmm … I don’t know I’m afraid.

It might be worth checking their comment (line 31+) in their go code, as below :slight_smile: That would appear to explain the mysterious fly-global-services.

Since you’d think you could simply do (from the node docs) server.bind(2000); // Prints: server listening 0.0.0.0:2000

7

Ah, I see, I’ll do some testing later, seems like fly is having some issues right now unless it’s just me, I’ve tried deploying multiple times, and it simply hangs waiting for the machine to start.

I might have found the issue for the UDP server but not 100% sure until I’m able to deploy, although for the TCP server issue I had today, I’m not really sure why it didn’t work since it was working yesterday. I guess I’ll have to wait until everything is settled, and I’m able to deploy to test things out again :melting_face:

Thanks for the help so far!

8

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