what would be the basic structure for UDP multiplayer server/client

Networking & Multiplayer
#1

Hello guys,
im too newbie to network multiplayer games but i’ve decided to try UDP for testing purposes,
in first intance i want to make a lobby but i want to ask you if my structure is enought:
CLIENT:



gameloop
{

update(); -> receive and send datagram packets in the update method, but i think this will block the thread
render();

}

i must spawn another thread inside UPDATE method, noly for receive data of the server?

SERVER

gameloop
{

update(); -> send and receive data of all clientes
render();

}

or i must spawn a separate Thread, for incoming packets?

ANOTHER QUESTIONS:

how can attach many clients in the server: when a datagram is received i can check the inet address and store this address in a list or array?

can i process the receive and send data in the same thread?

NOTE: this is raw JAVA i want to know the functionality.
thanks in advance.

#2

For a lobby, you should use TCP not UDP, as latency isn’t a concern.

As for threading; you need to look into blocking & non-blocking I/O.

#3

Have some links!

#4

thanks, but its not for hobby i want to learn the good way, today im learning but i think to make it profesional in near future,
by the way, i want to accomplish multiplayer online, not masive, but several connections to server y i’d like to be non blocking,

what kind of connections have, games like, ragnarok online, tibia or Mass Effect 3 in multiplayer, those are TPC or UDP?

#5

The link ra4king gave you is basically ‘the word of god’ when it comes to networking games.
The articles there cover the theory behind practically every networking concept.

There’s also an excellent video from GDC2015:

#6

mmm how can i say it,
those pages are so good, but what i want right know y the experience of another programmers who have been dealing with the same, i would change the question to:

how doyou guys think the proccess might work? base due your experience, im too far to make profesional things, im still reading, but i need to test thing to learn how they work, with your help and the info on those pages i will do it, but sometimes i need a faster and easy respose, like “in the first thread ( the game loop ) if you read data from socket you can block the program” i ask those questions because im not sure if im doing well or dont and im loocking for a little guidance.

i was reading past post here, and there was a guy who was doing something like multiplayer with UDP, after that he upload some videos of 2 cocks, i dont know if he is still active but i would apreciate check those kind of examples or documentation.

#7

You should study how both TCP and UDP work, especially using the link I posted. Figure out the differences between them and their uses. Read more articles about practical uses with them. The difference is enough to be able to make a decision on which protocol to use for the kind of data going through the connection.

#8

i know how each protocol works, but there is 2 ways:

1.- create a server and for non blocking each client must be in a separate thread, this means when a client make a connection the server must spawn a new thread, but this is not reliable

2.- non blocking, but this way its a little more complex, thats what im studying right now.

the first way is more easy but its oudated too

#9

No such thing as outdated, again: it’s simply use case. In the lobby, there isn’t much intensive work being done on the server thus it’s easy and cheap to have a thread-per-client with a blocking TCP socket (since game creation). In-game however, there is a lot of action and you definitely don’t want blocking there, so use non-blocking UDP or TCP depending on how much latency you can afford.

#10

i wont be using too much process, i just want to make an easy functional game but doesn’t need to be blocking,

i’ll make some RPG and i will use UDP, im actually creating my game protocol, i mean im creating the format of the request and responses the game will use, until now i think i can do something basic, but im still reading a lot of articles and questions of some game forums.

how can i create the objects of the client once im connected to it?
for example im logged and i will starting a match with another 3 players, then the server will create all objectos to be used:
monsters, bullets, items, 4 players,

what can i do? sending a response to all clients for example “createmonster:slime:10,5,1”
format is: “kind of object to crate, monster type, hp, experience, money”


//in the client gameloop
{
String rec = socket.receive(response); //
String []r = split(rec,":");//split the formated string in chunks

if(r[0]=="createmonster")
{
switch(r[1])
{
case "slime":
//create new object, set hp, exp, money
//add to the monsterPool of the cliente
break;
.
.
.
}


}



}

this would be a good aproach or im wrong?
any suggestion would be apreciated.
thanks guys again.

#11

You shouldn’t use UDP to build games, at least not without a lot of extra complexity,
for the simple reason that UDP is not guaranteed to be reliable. UDP messages
can arrive out of order, or not at all. You can use UDP for non-critical messages
such as the instantaneous mouse position, but anything that affects the flow of
the game has to be sent reliably.

This leaves you with two choices. Either use TCP for “important” messages, and
somehow integrate the non-synchronized TCP and UDP streams, or add a layer
of complexity to your UDP messages to add TCP-like reliability guarantees to
the important messages.

#12

True enough, reliability is the crux of the issue.
Though there are many ways to achieve reliability, and while TCP’s implementation is a good general purpose solution, for games where latency is a concern & packet loss is probable, its behaviour is pretty horrible.

So I’d never say “You shouldn’t use UDP to build games”.
You should use UDP when you know that the performance characteristics of TCP are unacceptable.

Though the OP’s question sounds like he’s trying to run before he can walk.
Write your RPG 1st; don’t even think about how to make it multiplayer until you’ve finished making it work for 1 player.

#13

TANSTAFL. The reason TCP has “unacceptable” performance is that to fulfill the
in-order guaranteed delivery, sometimes you have to hold everything up while the
lost messages are transmitted. Adding reliability to UDP will incur the same penalty.

The internet and IP are based on throwing stuff on the floor if you get too busy,
and therefore are inherently unsuited to certain kinds of games, for instance multi-person
fast shooter games.

The OP ought to understand that before he invests a lot of time in a project.

#14

like you said, im still reading a lot, because there is not a reliable response in this topic, however i want to think that UDP is the better aproach here for me, because the packets sent by the server will have a timestamp or a time variable indicating wich packet is new,
for example if you are in postion 0,0 and a packet is not received by the client dont change the position but in the server you will have the new position, then if in your client your send another request to change the position, and the server responds again with the new position your character will be in the most actual position,

i think this is like LAG in games, by the way some articles said that UDP were better for games like rpg, where you need a lot of speed and process, i will master TCP and UDP anyway. but now im dealing with TCP.

#15

Not at all. There are many ways to add reliability to your custom UDP. TCP comes built in with other “features” as well like congestion avoidance which you can do without.

Then again for a lot of multiplayer games TCP is just fine and for others it’s cancer infused ebola herpes.

#16

[quote=“ddyer,post:13,topic:56037”]
That’s simply not true; as implied in my previous post, there are other ways of implementing reliability without incurring the massive latency spikes inherent with TCP’s strategy.

The simplest approach being to append all unack’ed packets each time you broadcast data, so when a packet goes missing, you simply wait for the next.
Of course this redundancy approach increases packet size significantly, but that’s a perfectly valid compromise if latency is your priority.

The point is, even on modern reliable connections, TCP is not the universal answer.

#17

http://fabiensanglard.net/quake3/network.php

Cas :slight_smile: