Question - Code [SOLVED] Reliable UDP

Discussion in 'GameMaker Studio 2 Community Tech Support' started by Pichu114, Apr 27, 2019.

  1. Pichu114

    Pichu114 Member

    Joined:
    Apr 27, 2019
    Posts:
    3
    When reading the documentation on network_set_config, we came across the "reliable UDP protocol" that GameMaker apparently supports. This protocol claims to guarantee that packets find their destination, without extra code on your end. For complicated reasons, our project cannot use TCP, so this seemed like a great way to send important data.

    The problem, however, is that there is no documentation on this feature. The documentation page shows incorrect function arguments, the listed example does not include this protocol and all that's listed is a brief explanation of what the protocol does. This raises a couple questions:
    - When calling network_set_config(network_config_enable_reliable_udp, ???), what is the second argument, if any?
    - Does this work on a per-socket basis, or does enabling/disabling this automatically apply to all sockets we're using?
    - Can this be enabled and disabled freely several times throughout the game, or are there limitations?

    As great as it would be to update the documentation to address these questions (and fix the incorrect "Setting" arguments), I realize this probably isn't going to happen anytime soon. Instead, I'd like to ask if anyone else has experience with this protocol, and share their experience to help us get started. Many thanks in advance!
     
  2. chamaeleon

    chamaeleon Member

    Joined:
    Jun 21, 2016
    Posts:
    1,063
    Stabbing in the dark here, but my guess for your questions would be that the second argument, being measured in millliseconds, is the time to wait until GMS automatically tries to resend a UDP packet. Since GMS behind the scenes is managing the transmission being successful, it needs to wait for some amount of time for some acknowledgement since UDP doesn't have it. With GMS managing the acks then, it seems reasonable to give the programmer some control over the time GMS should wait until trying to send again.

    Second question, since there is no socket argument, I'd say it applies to all sockets as soon as you toggle it.

    Sure, I imagine you could toggle it on and off throughout the game, however, the documentation does state that both ends of the connection have to have it enabled for it to work. A corollary to that is that if you disable/enable it in one end, you'd have to ensure it is disabled/enabled in the other end before sending another packet, or the receiving end would try to read too many or too few bytes and either misinterpret the extra bytes as your actual data, or attempt to read the first bytes of your actual data as part of the protocol header. That sounds very fragile to try to manage.
     
  3. PNelly

    PNelly Member

    Joined:
    Jun 20, 2016
    Posts:
    256
    I'm not so sure about "incorrect function arguments" (it looks fine to me) but you're right that it's a scant piece of documentation. You might submit a help desk ticket to see if you can get more info or reach out to a networking guru like @YellowAfterlife to see if they're familiar with the feature. Barring those options you might have to breakout wire shark and run some experiments to figure out what it does (not everyone's idea of a good time).

    My own two cents on your questions:
    - Packet receipt can only be verified if the sending machine gets a confirmation message back from the receiving machine. I'd guess the millisecond parameter is the amount of time allowed to pass before the sending machine re-launches a packet whose receipt was not confirmed. Of course I don't really know, but when I've implemented reliable udp it's the only place the need for a timeout surfaced.
    - Because a socket id isn't supplied to the function I'd think it has to be global
    - If it is what I think it is then you would want to be adjusting it according to the latency of your udp communication. Even though the docs can be challenging key limitations are usually named; who knows though. You might toggle it several thousand times and see what happens.

    Not the answer you're seeking but hopefully better than nothing.

    Patrick

    Edit: Shoutout to @chamaeleon for posting essentially the same thing at essentially the same time.
     
  4. Nocturne

    Nocturne Friendly Tyrant Forum Staff Admin

    Joined:
    Apr 13, 2016
    Posts:
    7,070
    Have you filed a bug about the issue with the documentation? All bug reports for Docs are fixed for the next update after the bug was reported, but if you don't report it then the fix ain't going to happen... ;)
     
  5. YellowAfterlife

    YellowAfterlife ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    2,469
    IIRC the second argument for both use_reliable and use_unreliable is the socket ID to apply to, but do some extensive testing with different player counts - I think it was originally introduced purely for some console-specific interop, and as of the last time I tried it (2015 or so), it would wait ~0.5s before resending lost packets (which is a bit too slow for some kinds of networking), so I ended up writing a custom wrapper for that project anyway.

    You can strip a reliability wrapper from GMNet if you wanted.
     
  6. Pichu114

    Pichu114 Member

    Joined:
    Apr 27, 2019
    Posts:
    3
    @chamaeleon @PNelly Thank you for your thoughts. My reasoning for the arguments being incorrect was that blocking upon disabling reliable UDP makes no sense, unless I'm missing something. Given that the description says "Enables the "reliable UDP" protocol for an existing UDP socket", I thought it would be logical to assume the socket should be passed as the argument. Your input has given me new insights though, I'll mess around with this more and see if your theories are correct!

    @YellowAfterlife That makes a lot of sense. ~0.5s would be fine for our project, since we'd only use it for menus, where extra delay isn't a big problem. Thank you for sharing your experiences!

    @Nocturne I wasn't aware that we could submit bug reports for the documentation, I thought this was for GMS2 itself only. Once I'm finished messing around and (hopefully) find out exactly how this works, I'll make sure to file a report and detail the mistakes, as well as what extra information should be added to help people out in the future.

    I will update this thread with my findings once I have figured everything out, so other people won't run into the same issues I did. Thank you all for your help!
     
    matharoo, PNelly and Nocturne like this.
  7. Pichu114

    Pichu114 Member

    Joined:
    Apr 27, 2019
    Posts:
    3
    I was able to get it working, so as promised, here are the answers to my questions:
    - The second argument is, as YellowAfterlife said, the socket ID for this protocol to apply to.
    - This protocol works on a per-socket basis, meaning you can enable it for certain sockets and disable it for others.
    - I could not find any limitations. As long as it is managed properly, it appears that you can enable and disable it freely.

    The second point allowed me to have separate sockets, one for reliable UDP (menus), and another one for regular UDP (in-game data). I found this to be easier to manage than enabling and disabling it at the correct times, but that method should still work.

    I also filed a bug report about the documentation page. Thank you all again for the help!
     
    matharoo and chamaeleon like this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice