multiplayer issue

[gabriel-tandil]

Platforms

Android

Build

release build 146

Issue

I found it reported as #10106 but it was closed due to insufficient data, I provide more information and if you need more data or to do some testing I am available and well qualified to do it.

It happened to me on both android and linux platforms.

Other players see my server, and although the screen initially shows that there is an error connecting, they are able to connect. In my game I see them immobile but they see the map but do not see their player.

Another piece of information... Playing the same game on the local network works, but if even from the machine that has the server I try to connect as a game on the internet then it fails.

I open my game for multiplayer

I have the port redirected in my router correctly.

Kazam_screencast_00001.mp4

Steps to reproduce

1. start server (can be the standalone server or from the game)
2. from another machine try to connect to the game (can be by ip or by domain)
3. the map loads but the player is not visible.

Mods used

none

Save file

here is
multiplayerError.zip

(Crash) logs

none

Submission

• I have updated to the latest release (https://github.com/Anuken/Mindustry/releases) to make sure my issue has not been fixed.
• I have searched the closed and open issues to make sure that this problem has not already been reported.
• I am not using Foo's Client, and have made sure the bug is not caused by mods I have installed.

[camelStyleUser]

what port forwarding rule do you have

[camelStyleUser]

is it UDP+TCP 6567->6567(or some other mindustry server ports)

[gabriel-tandil]

is it UDP+TCP 6567->6567(or some other mindustry server ports)

@camelStyleUser exactly

[Anuken]

Does this issue still occur in the bleeding edge builds?

[Anuken]

Additionally, are you capable of building the game yourself for testing, or would you rather I build them myself/commit to master for a BE build?

[gabriel-tandil]

Does this issue still occur in the bleeding edge builds?

Tnx! Next week I'll try that

Additionally, are you capable of building the game yourself for testing, or would you rather I build them myself/commit to master for a BE build?

i guess I can build th game by myself, I'll try

[SITUVNgcd]

This is look like Vars.logic.reset() on server.

[gabriel-tandil]

@Anuken I already tested with the latest version listed in bleeding edge builds and the problem occurs the same way.

I still couldn't successfully build the game from the Anuken/Mindustry git but I'm working on it.... Any idea what I can verify with a version built from there when I succeed?

[gabriel-tandil]

I can now make my custom build, I remain attentive.

[Anuken]

I am away from home for the next week, and as such will have very limited time to help with this right now.

One thing that may help shed some light in this issue is:

• Enabling the console (Game settings)
• Joining your server
• Opening the console (F8)
• Typing Call.requestDebugStatus() and pressing enter
• Screenshotting all the resulting output in the console (if any) and posting it here

[gabriel-tandil]

here is

[way-zer]

UDP stream from server to client is fail.

[gabriel-tandil]

UDP stream from server to client is fail.

@way-zer I don't think it's that...
I try the UDP communication through the port with
$ nc -ul -p 6567
on the machine where the server would run, and
$ echo “test udp” | nc -u gabrieltandil.ddns.net 6567
on a machine with a different internet connection and the data flows correctly.

[Anuken]

The strange thing is that the connection requires functioning UDP to work properly; otherwise, it would fail to connect with a timed out during UDP registration message. Something else is going on here.

[way-zer]

The strange thing is that the connection requires functioning UDP to work properly; otherwise, it would fail to connect with a timed out during UDP registration message. Something else is going on here.

The handshake process only involves TCP C->S TCP S->C UDP C->S, but no UDP S->C.

[way-zer]

UDP stream from server to client is fail.

@way-zer I don't think it's that... I try the UDP communication through the port with $ nc -ul -p 6567 on the machine where the server would run, and $ echo “test udp” | nc -u gabrieltandil.ddns.net 6567 on a machine with a different internet connection and the data flows correctly.

This is still test oneway, from C->S, not S->C

[gabriel-tandil]

Thanks for your answers @Anuken and @way-zer

Then surely the problem comes from that side if bidirectional UTP flow is expected.

A possible first improvement would be to inform the user about the specific error with some message.

Anyway I think you should consider whether using UTP “bare metal” is a good idea for bidirectional communication, since not being connection oriented these problems can occur by NATs in the middle for example.

One possibility would be to request that the clients also have an open UDP port on their machine and router, although it would make the configuration more complicated for the players.

[gabriel-tandil]

The strange thing is that the connection requires functioning UDP to work properly; otherwise, it would fail to connect with a timed out during UDP registration message. Something else is going on here.

@Anuken , as I originally commented in the server list it shows that there is an error, but it doesn't give any details and it still allows to enter

[way-zer]

Under normal circumstances, NAT will maintain port mappings, even for UDP. Since many programs only use UDP and require two-way communication, this is not a problem. So, I think this is not a problem of Mindustry.

For Mindustry, adding UDP verification in the handshake phase will lead to incompatibility. In addition, UDP is inherently unreliable, which may increase the possibility of handshake failure (UDP will be drop if server upload bandwidth is almost full) and cause confusion.

the server list it shows that there is an error

Server list uses only UDP for ping, There is a problem with your UDP connection, so an error will be displayed.

[way-zer]

This is an individual problem, you may need a dedicated server. Even I have encountered it, because of the operator's poor QoS policy, there is nothing the game itself can do except changing the cloud server provider.

I think this issue can be closed.

[gabriel-tandil]

Well, if you want to close it that's fine.
I think it's a problem that affects several people and can be improved (I actually saw this reported in other tickets in the past). Many ISPs have similar policies and although not ideal it is possible to use them.

Anyway I opened the ticket with the hope that my comments and tests will serve to improve the game, which is very good anyway. I don't know if I can contribute anything else.

[way-zer]

It's not easy to improve. Many games use UDP and the connection can't be pure TCP, otherwise the congestion problem will be severe.

Just adding one error does not improve the user experience, and this is the only one can be improved.

[gabriel-tandil]

I understand, that's why I suggested to open a port in the client's router as well, although I understand that this solution may not be good for everyone.

But I leave you the concern, it is a subject that can be improved although it may not be simple, while vpn service vendors at least have their business 😆

Anyway I think that a more detailed error would be helpful for users. 🙏

[way-zer]

open a port in the client's router

client's router has no reason to drop the packet, opening a port don't mean you can receive packets. So client can't do anything for this, also the game itself.

[gabriel-tandil]

Maybe I didn't explain well what I meant... a UDP channel on an open port on the server router for C->S direction communication (that's what currently has no problems) and another UDP channel on an open port on the client router for S->C direction communication. This way there would be bidirectional communication with the advantages of the UDP protocol without the difficulties that the current approach is bringing.

[way-zer]

Normally, if you could receive packets from client, you are able to send packets to client use the same connection.

[gabriel-tandil]

I understand your point, it is just a possible solution for something that can often fail. Anyway thank you for your attention and your answers.

[Anuken]

For Mindustry, adding UDP verification in the handshake phase will lead to incompatibility. In addition, UDP is inherently unreliable, which may increase the possibility of handshake failure (UDP will be drop if server upload bandwidth is almost full) and cause confusion.

What about the confusion caused by situations such as this, where the UDP S->C connection doesn't actually work? Isn't it better to fail early if the server can't establish a proper connection?

[gabriel-tandil]

What about the confusion caused by situations such as this, where the UDP S->C connection doesn't actually work? Isn't it better to fail early if the server can't establish a proper connection?

Yes, I think that showing a fault (and if possible adding some details of the cause) would be the best thing to do.

[way-zer]

What about the confusion caused by situations such as this, where the UDP S->C connection doesn't actually work? Isn't it better to fail early if the server can't establish a proper connection?

You can add verification, but it's better to keep resending the UDP packet periodically (1s) before the timeout and verification. (A single UDP packet cannot be guaranteed to be received)

EDIT: maybe we could reuse StateSnapshotCall. Disconnect and give error if in game and not receive after timeout(5s/10s/15s)

[lyl-1520202]

Kiedy powstaną guzy i gwiazdy E?

[lyl-1520202]

Kiedy powstaną guzy i gwiazdy E?