Jump to content

Dedicated Server on Docker Network Issues ??


Recommended Posts

I was trying to run a dedicated server on docker and I have run one in the past but the current install of the game has some undocumented network information 

First I tried here

https://github.com/Jamesits/docker-dst-server

 

and the shards connect and both work 25% of the time the rest of the time 

 

Quote

dst_master  | [00:00:38]: [Shard] Secondary shard Caves(190508827) connected: [LAN] 172.25.4.3
dst_caves   | [00:00:27]: Validating portal[1] <-> <nil>[1] (inactive)
dst_caves   | [00:00:27]: Validating portal[2] <-> <nil>[2] (inactive)
dst_caves   | [00:00:27]: Validating portal[3] <-> <nil>[3] (inactive)
dst_caves   | [00:00:27]: Validating portal[4] <-> <nil>[4] (inactive)
dst_caves   | [00:00:27]: Validating portal[5] <-> <nil>[5] (inactive)
dst_caves   | [00:00:27]: Validating portal[6] <-> <nil>[6] (inactive)
dst_caves   | [00:00:27]: Validating portal[7] <-> <nil>[7] (inactive)
dst_caves   | [00:00:27]: Validating portal[8] <-> <nil>[8] (inactive)
dst_caves   | [00:00:27]: Validating portal[9] <-> <nil>[9] (inactive)
dst_caves   | [00:00:27]: Validating portal[10] <-> <nil>[10] (inactive)
dst_caves   | [00:00:27]: Received MasterInfoPacket row ea4316891287807e6bb7c127eb44f7bf region us-east-1

 

They say connected but dont connect.... to each other

 

if you keep trying 


 

Quote

 

dst_master  | [00:00:37]: Validating portal[10] <-> 190508827[10] (disabled)
dst_caves   | [00:00:27]: World 1 is now connected
dst_caves   | [00:00:27]: Validating portal[1] <-> 1[1] (active)
dst_caves   | [00:00:27]: Validating portal[2] <-> 1[2] (active)
dst_caves   | [00:00:27]: Validating portal[3] <-> 1[3] (active)
dst_caves   | [00:00:27]: Validating portal[4] <-> 1[4] (active)
dst_caves   | [00:00:27]: Validating portal[5] <-> 1[5] (active)
dst_caves   | [00:00:27]: Validating portal[6] <-> 1[6] (active)
dst_caves   | [00:00:27]: Validating portal[7] <-> 1[7] (active)
dst_caves   | [00:00:27]: Validating portal[8] <-> 1[8] (active)
dst_caves   | [00:00:27]: Validating portal[9] <-> 1[9] (active)
dst_caves   | [00:00:27]: Validating portal[10] <-> 1[10] (active)
dst_caves   | [00:00:28]: [Shard] secondary shard LUA is now ready!
dst_caves   | [00:00:28]: Sim paused


 

 

it may work ....

 

 

So I tried another docker project 

 

this one 

https://github.com/mathielo/dst-dedicated-server

 

and the issue was the same working some of the time.....

 

 

At this point I see both docker projects were on Debian so I decided I will just build an image on Ubuntu myself...

After getting it setup

build

docker pull tws101/dst-dedicated-server:dev_0.01.0

and git

https://github.com/tws101/dst-dedicated-server

 

using dev branch

 

 

Compose

networks:
  dst:
    name: dst
    ipam:
      driver: default
      config:
        - subnet: 172.25.4.0/24
          ip_range: 172.25.4.0/24
          gateway: 172.25.4.1
services:
  dst_caves:
    container_name: dst_caves
    image: tws101/dst-dedicated-server:${VERSION}
    user: 1001:1001
    ports:
      - 11000:11000/udp
      - 27019:27019/udp
    networks:
      - dst
    links:
      - dst_master
    environment:
      - SHARD_NAME=Caves
    volumes:
      - ${DST_CONFIG}:/home/dst/config/DoNotStarveTogether/Cluster_1
  dst_master:
    container_name: dst_master
    image: tws101/dst-dedicated-server:${VERSION}
    user: 1001:1001
    ports:
      - 10998:10998/udp
      - 10999:10999/udp
      - 27018:27018/udp
    networks:
      - dst
    environment:
      - SHARD_NAME=Master
    volumes:
      - ${DST_CONFIG}:/home/dst/config/DoNotStarveTogether/Cluster_1
    stdin_open: true
    tty: true

 

I am working no differently that the other two projects about 25% of the time ... So I was about to give up and I decided to run the server in offline mode  and ALL OF THEM WORK EVERYTIME (all three projects)

and I know the first one was working a few years ago...

 

So I take it this is a network issue and if I could put a server on a public IP directly I would have no issues

So what is the correct network setup

image.png.94e799684945860eb525e32efb868f7e.png

 

10998  is forwarded to master UDP 

10999  is forwarded to master UDP

27018  is forwarded to master UDP

 

11000  is forwarded to caves UDP

27019  is forwarded to caves UDP

 

I see these other port being used....   like 50462... but then it changes

 

What are they for?

 

What needs to be forwarded to get a server to come up in online mode every time?

Or what setting are needed at build so to force these other ports to be consistent so I can forward them as well?

 

 

Any current this year documentation would be very helpful, I will maintain the project for a few years if I can get it up and going.

 

Ports that look like 50462 usually are the source ports. Aka the outgoing source ports which get's used by the server to access something from. As such these ports shouldn't be necessary to be bothered with.

Ports 27018 (on Master) and 27019 (On Caves) should be accessible from the internet for players to connect to.

Ports 10998 or 10999 and 11000 (Not sure which ones specifically) should be accessible from the respectively other shard.

So It should look something like this:

src: * ; dest: Master ; src port: * ; dest port: 27018
src: * ; dest: Caves ; src port: * ; dest port: 27019
src: Master ; dest: Caves ; src port: * ; dest port: 11000
src: Caves ; dest: Master ; src port: * ; dest port: 10998 or 10999

Optionally, if default outgoing is not open (Not much xp with docker, but I think this should be unnessesary):
src: Master ; dest: * ; src port: * ; dest port: 443
src: Caves ; dest: * ; src port: * ; dest port: 443

3 hours ago, nome said:

Something to note: for real-time UDP connections I've generally seen it recommended to use host networking on docker to avoid the latency overhead of going through vnet interfaces.

 

Ah I can try this latency is extremely low on this server...  But I will try it

 

Also I am starting a second imagining on this 

https://hub.docker.com/repository/docker/tws101/docker-dst-server/general

What I notice is the server does register the Cave shard completely but it take hours.....  I still think this is some other network issue...

 

loads like this 

image.png.b57f7c9a615fb7988bbfc9cce594deeb.png

 

image.png.5886ce14efe12effc17e98849a461c1e.png

 

an an hour or two later it the portals will go active

 

Is there some TCP port that is needed to or it it just the UDP ports?

 

I am seeing only the lower UDP port even getting hit

image.png.48b47b07a1e38433735db29895644edf.png

 

10999 and 11000   does are NATED direct to the docker host and the compose nats those in again direct to the container

 

trying this now

image.png.134f5e59b9a0ca55a539916014a3d2f6.png

will change network mode to host and try that as well

 

 

3 hours ago, nome said:

Something to note: for real-time UDP connections I've generally seen it recommended to use host networking on docker to avoid the latency overhead of going through vnet interfaces.

Tried host network mode 

image.png.72c23d342d0e34a144cf650113b2e262.png

 

image.png.db63d7d27423311f0a63f27a152fe5ea.png

 

Still does not sync immediately or reliably...  

image.png

image.png

Once again it syncs after hours 

 

image.png.039788b7277a36ba93263c738727f7dd.png

 

every strange

 

Any ideas?

 

 

 

 

 

 

Since I have two of these built I will be putting my energy into maintaining only one of them

and that will be this one 

https://github.com/tws101/docker-dst-server

https://hub.docker.com/r/tws101/docker-dst-server

 

 

Looking at your config, I see some lines with something like this:

10999-11000:10999-11000/udp

Afaik the first two are the source ports. If the shard tries to access the port 11000 using the port 53129 it fails. It might eventually hit one of the two ports you've allowed, which is why it syncs after half an hour or so.

Try setting it to

*:10999-11000/udp

or maybe even

10999-11000/udp

 

7 hours ago, Daniel86268 said:

Looking at your config, I see some lines with something like this:

10999-11000:10999-11000/udp

Afaik the first two are the source ports. If the shard tries to access the port 11000 using the port 53129 it fails. It might eventually hit one of the two ports you've allowed, which is why it syncs after half an hour or so.

Try setting it to

*:10999-11000/udp

or maybe even

10999-11000/udp

 

I am starting to believe Klei is blocking back to back server registration with the same cluster token.....  Like a server restart flood limit

Seem if I start it fresh without having started it recently it tends to work immediately each time....

 

 

But as for your response why the registration server be coming in on 53129  ??

 

 

 

***THIS was likely a flood limit

 

I have two servers working nicely adding an island of adventure 4 shard version now

3 hours ago, tws101 said:

But as for your response why the registration server be coming in on 53129  ??

That was just a random port number as an example I generated by randomly tapping number keys on my keyboard.

Glad you figured it out!

Though I'd find it strange if there'd be a flood limit since running two shards at the same time (with one token) is the intended use case.

On 10/18/2024 at 2:00 AM, Daniel86268 said:

Looking at your config, I see some lines with something like this:

10999-11000:10999-11000/udp

Afaik the first two are the source ports. If the shard tries to access the port 11000 using the port 53129 it fails. It might eventually hit one of the two ports you've allowed, which is why it syncs after half an hour or so.

Try setting it to

*:10999-11000/udp

or maybe even

10999-11000/udp

 

The problem does appears to have disappeared....  

 

Setting ports to *:10999-11000  would be impossible that would publish all port to the host (in docker I dont think this would even be allowed...  The docker host would have no ports left...  also it would conflict that all the others container published ports.

 

Just to give you an idea of the network setup

 

Router with public ip listening on 10999 and 11000 UDP  if those come in on the WAN port it is blind forwarding those two straight to the docker host on the same port numbers

Docker host receives those two 10999 and 11000 UDP and based on that rule you see int he compose forward them into the container also to the same port numbers

 

I guess I would never assume the DST server would use ports other than what it is designated to listen on in its config...  Does it listen on ports other than what is in the config file? 

 

 

Here is why all ports cant be forwarded

 

image.png.f50421d86de0cae863c75410e4b8e3f4.png  

image.png.6bd321fedb9a9c4ff5ae7a75a3a25bfc.png

 

As you can see we have a few other things the server needs to do other than just run DST...

 

But as of now DST on both of those dedicated server (running two of them)

they are now running fiddle

https://hub.docker.com/r/tws101/docker-dst-server

 

Running the basic and the island build 

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...