The Tutorial:Networking_with_UDP isn't very helpful on this subject. I already know how to pack, send, receive and unpack, but how do I find out who send what? I know I can get the data, IP and port through
Do you set peer name? If so, the implementation will ignore datagrams from everyone but specified peer.
Anyway the IP and port are the only pieces of identifying data you will get. Needless to say, that's not strong enough information to bind users by, so you must implement your own identification scheme. TCP does this implicitly, but also it requires that packets go through, it doesn't just drops them if they fail the first time, which is bad for realtime networking. If you only do stuff like sending messages and turn-based events, then TCP is preferred. In an action game, you should use both, UDP for immediate bulk data and TCP for high reliability events.
raidho36 wrote: ↑Sun Mar 25, 2018 4:53 am
Do you set peer name? If so, the implementation will ignore datagrams from everyone but specified peer.
Anyway the IP and port are the only pieces of identifying data you will get. Needless to say, that's not strong enough information to bind users by, so you must implement your own identification scheme. TCP does this implicitly, but also it requires that packets go through, it doesn't just drops them if they fail the first time, which is bad for realtime networking. If you only do stuff like sending messages and turn-based events, then TCP is preferred. In an action game, you should use both, UDP for immediate bulk data and TCP for high reliability events.
Well, I'm trying to implement an algorithm that registers clients in a table and removes them if the connection is lost, but I just realized I don't understand how udp:receive() works. If I have three clients open, I will receive data from the first one on a frame, data from the second one on the second frame, and from the third one from a third frame?
Sockets are supposed to queue up messages so you need to drain them empty every time you access them. Not sure what this implementation does but do try reading from a socket in a loop until it's empty.
Also by design UDP sockets don't maintain any connection. They just send packets to specified destination and hopefully they will arrive, and they read whatever had arrived. Hence you don't need to bind UDP sockets to addresses, listen to connections, etc. Think delivering data on hard drives by truck as opposed to telegraph transmission, if somehow trucks were faster to get there than wire signal.
Last edited by raidho36 on Sun Mar 25, 2018 7:19 am, edited 2 times in total.
In other words, no; it receives all data when it receives it, and you'll need to send frame data as well, if you have syncing needs.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.