TimonPost / laminar

A simple semi-reliable UDP protocol for multiplayer games
821 stars 66 forks source link

Laminar sometimes sends duplicated reliable messages #266

Open mvlabat opened 4 years ago

mvlabat commented 4 years ago

Sometimes Laminar sends duplicated reliable messages.

Here's the code I tested reliable messages with: https://github.com/mvlabat/laminar_test_reliable It's built on amethyst_net (that's the simplest way I could make a working reproducible example).

This is the log I've got for server binary:

[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:60,abs_time:2.0129027"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:120,abs_time:4.0126003"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:180,abs_time:6.0121002"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:240,abs_time:8.0118525"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:300,abs_time:10.0112636"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:360,abs_time:12.0107855"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:420,abs_time:14.0102495"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:480,abs_time:16.0098564"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:540,abs_time:18.009468"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:600,abs_time:20.0090189"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:660,abs_time:22.0084704"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:720,abs_time:24.0078973"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:780,abs_time:26.0074167"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:840,abs_time:28.0138444"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:900,abs_time:30.0133461"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:960,abs_time:32.0129481"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1020,abs_time:34.0125258"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1080,abs_time:36.0120126"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1140,abs_time:38.011648"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1200,abs_time:40.0111007"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1260,abs_time:42.0106031"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1320,abs_time:44.0101689"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1380,abs_time:46.0097797"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1440,abs_time:48.0093349"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1500,abs_time:50.0087834"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1560,abs_time:52.0084059"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1620,abs_time:54.0078647"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1680,abs_time:56.0074363"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1740,abs_time:58.010088801"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1800,abs_time:60.009485601"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1860,abs_time:62.008991301"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1920,abs_time:64.007861001"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:1980,abs_time:66.007326101"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:2040,abs_time:68.011057001"
[INFO][server] 127.0.0.1:3455: b"CL: sim_frame:60,abs_time:2.0129027"

Note the first and the last lines ^ (the first message sent on 60'th frame was received twice).

I'm not sure this is 100% reproducible, but with some "luck" it is (I've got the same log two times in a row). I suppose the key to see it is to wait for at least REDUNDANT_PACKET_ACKS_SIZE (32) packets.

fhaynes commented 4 years ago

@TimonPost @jstnlef did you two look at this?

kstrafe commented 4 years ago

@mvlabat my guess is that it's because the client never seems to read from the channel of incoming messages so it doesn't register them in the bitset of acknowledged messages to send back.

If not, where can I find the API of send_with_requirements? Looked at amethyst_network and amethyst docs but the symbol doesn't seem to exist.

mvlabat commented 4 years ago

@BourgondAries I think you were looking at stable documentation. You can find send_with_requirements in the latest master version of Amethyst. The docs are available here, but they're returning 404 error right now :( But you'll surely find that method in the source code of amethyst_net.

I believe that client does read from the channel of incoming messages.. I'm not very familiar with amethyst_net or laminar codebase, but it seems to me that LaminarNetworkRecvSystem (amethyst_net) is doing exactly this (which is included in the LaminarNetworkBundle I use). I'm just not sure if that way of reading incorporates sending acknowledgements

TimonPost commented 4 years ago

@fhaynes I did some time ago. There are some weird things happening in the reliability layer. It is a debugging hell. Since then I haven't looked at yet. You will have to make sure that you've completed the server-client handshake. Which is a client to server and server to client packet exchange. Then it should not sent any duplicates. In order to validate this issue, we need some sample code.

I can't promise any time devotion now. Maybe later.

filippo-orru commented 4 years ago

Seems like I'm having this issue as well.