GameMaker test for connection and disconnection in udp

[Shadowblitz16]

can someone give me an example of how to test for a connection and disconnection in udp?

I wanted to bypass the server object directly and just have everything in the client object and have it auto detect which is the server, however since its a connectionless protocol I'm not sure how to test if someone had disconnected or connected.

/// @description Create Server

var type      = network_socket_udp;
var port      = 8000;
socket        = network_create_socket_ext(type, port);

remote_port   =  0;
remote_ip     = "0.0.0.0";

send_buffer   = buffer_create(1024, buffer_fixed, 1);

/// @description Sync Server

var type = async_load[? "type"]

switch(type)
{
    case network_type_connect:
        remote_port = async_load[? "port"];
        remote_ip   = string(async_load[? "ip"])
        break;
}

var buffer = async_load[? "buffer"]
buffer_seek(buffer, buffer_seek_start,0);
process_packet(buffer);

 

[Carl Nylander]

as you said, udp is connectionless which meen you have to make up your own connect and disconnect messages.
a timeout message is also importent to check if someone left the game ungracefully.
I almost allways use the first byte in the network message to determin the typ of message. maybe 100 is connect, 101 is disconnect, start moving is 10, fire a weapon is 20 and so on...

 

[Shadowblitz16]

this doesn't make sense how are connections and disconnections handled then?

 

[Carl Nylander]

one computer open up a port for udp trafic and the other computer simply send messages to that port.
in TCP there is a handshake were both computers agree to follow a set of rules before they can start sendig messages between each other.

 

[jaydee]

this doesn't make sense how are connections and disconnections handled then?

You’ve said it yourself already, Udp is connectionless. They aren’t handled within the protocol, they do not exist. So if you want to implement something similar to those events, you will have to code the protocol to do so yourself.

It’s really important to consider whether tcp or udp is the best protocol for you, as the biggest differences between them is that tcp has connections, guaranteed packets and network traffic control built in.

As @Carl Nylander suggests, use header bytes to determine the type of packet. And use ping packets to monitor for ungraceful disconnections. (Eg, if a clients internet fails before they send the disconnect packet).

(Interestingly, the underlying protocol that udp uses actually does generate connect/disconnect events but you cannot access those in GMS.)

 

[The-any-Key]

The UDP tuple in a router with firewall may exists for about 30 seconds. If no message is received/sent the tuple will die and the line be lost. You get "disconnected".
You can prevent this by send a keep alive packet. Note that the UDP messages may not get to the other end. So I usually send a ping every 15 seconds with a stay alive message and use it as a ping that keep the tuple line open. With this ping you can handle the disconnect manually. If you dont get a ping from a client after 60 seconds, it has disconnected. Best practice is to send the keep alive packets from both sides: server<>client to make sure you are within the 30 seconds timeout.

One of the main reasons UDP packets don't get delivered is that they are too big. There is a 700-1500 byte send limit in routers for WAN, so make sure you send max 700 bytes in one message. LAN mostly don' have a limit.

 

[Shadowblitz16]

ok so basically I send a connect packet when the udp connection is started and send a disconnect packet when the game ends?

 

[flyingsaucerinvasion]

The UDP tuple in a router with firewall may exists for about 30 seconds. If no message is received/sent the tuple will die and the line be lost. You get "disconnected".
You can prevent this by send a keep alive packet. Note that the UDP messages may not get to the other end. So I usually send a ping every 15 seconds with a stay alive message and use it as a ping that keep the tuple line open. With this ping you can handle the disconnect manually. If you dont get a ping from a client after 60 seconds, it has disconnected. Best practice is to send the keep alive packets from both sides: server<>client to make sure you are within the 30 seconds timeout.

One of the main reasons UDP packets don't get delivered is that they are too big. There is a 700-1500 byte send limit in routers for WAN, so make sure you send max 700 bytes in one message. LAN mostly don' have a limit.

So, if you need to send a packet which is much larger than that, is it enough just to break it up into 700 byte parts, and then send all of those all at once, or do you have to space them out over time as well?

 

[Dog Slobber]

You do not need to split packet size up. And routers do not necessarily have a WAN packet size limitation of 700-1500, and LANs do have limitations.

Size limitations exist for all network architectures they are defined by the Maximum Transport Unit (MTU) and configured on every routers port depending on it's architecture. The dominant architecture for most LAN technology is Ethernet which has an MTU of 1518.

Creating packets larger than the MTU is not a problem because IP will split it up (fragment) it based on the underlying MTU size. IP also puts the packet back together again at the final destination.

Be aware that packets that travel over WANs will likely travel over networks with unknown MTU sizes.

Although fragmenting packets isn't that much of a problem it should be avoided for efficiency sake. The process of fragmentation and putting packets back again can be costly.

Also be aware that Ethernet MTU is the frame size not the payload (date) size. The maximum typical payload is:
MTU - ethernet header (18) - IP header (20) - UDP (8) or TCP (20) Header size

1518 - 18 - 20 - 20 = 1460 (TCP over Ethernet)
1518 - 18 - 20 - 8 = 1472 (UDP over Ethernet)

An interesting exercise to determine the maximum packet size to a destination without fragmentation is to use ping with the -f and -l switches.

ping -f -l 1400 google.com

Intstructs ping to send a packet size of 1400 to google and not to fragment. You then increase the packet size until it fails. This will be the maximum payload size between the two destinations (without fragmentation).

ie
ping -f -l 1400 google.com //should work
ping -f -l 1450 google.com //should work
ping -f -l 1472 google.com // should work
ping -f -l 1473 google.com // should fail

The maximum payload for an ICMP packet between my host and google is 1472.

Equivalent ping commands for Mac and Linux are:

Mac - ping -D -s 1472 google.com
Linux - ping -M do -s 1472 google.com

It should also be noted that some sites will not allow fragmented packets within their networks to reduce DOS attacks from oversize packet exploits.


Bottom line: Ensure your data size is no larger than 1460 and it will work fine with no fragmentation over TCP/UDP over ethernet and most network architectures.

 

[The-any-Key]

So, if you need to send a packet which is much larger than that, is it enough just to break it up into 700 byte parts, and then send all of those all at once, or do you have to space them out over time as well?

You can send it in the same step. Note that GM seems to ignore sends if you send >160 messages in one step.

Bottom line: Ensure your data size is no larger than 1460 and it will work fine with no fragmentation over TCP/UDP over ethernet and most network architectures.

If you plan to have the game play online between USA<>Europe<>Asia you should max send 700 bytes. We had some issues when we used a 1000-1400 bytes size in some play tests. And the solution was to manually split the buffers to 700 instead. Even if it should work with a larger payload, it simply didn't in our tests.