18 replies to this topic

[Luna]

Hey ^^
I need help with my UDP code! if someone could explain to me how to work with "acks" and how to set them.

My boyfriend and I are working on a 3D game, we already made basic UDP send/receive code (though quite forgot about it for a while ^^), but as we understand, packets can be lost with UDP and we need some sort of flow control.

I didn't manage to find a place with a good example..

I am also wondering how to avoid memory leaks with copied data from the multi player code.
Right now I made a "GetPacket" function which retrieves a packet from the received messages queue in the UDP class.
But since the memory is dynamic char string (char packet = new char[packetsize]), it means that they could play with the pointer and lose it.
I could make a maximum size and define all chars size to be char[MAXIMUM_SIZE] instead of dynamic or maybe make a class to handle it.

So I am looking for opinions if anyone has ^^ and if someone thinks they have the time to explain me about acks and flow control over and maybe the memory stuff,
I would be grateful ^^

My skype is lunanishry
And MSN Messenger is Luna.Nishry@gmail.com

[fatboy]

Flow control in unreliable networks is something you probably don't want to take on. It is and continues to be a basic research problem with multiple partial solutions. Either adapt your application to accommodate unreliable comms (i.e. your app doesn't care if it misses a message since it only requires a "loose" local state estimate) or, if you're on a wired or otherwise reliable network, use TCP.

Good luck!

Edited by fatboy, 09 March 2009 - 11:54 PM.

[nanostuff]

If it's a turn based game, use TCP. If it's real-time, you're going to have a problem. If timing is not critical, such as a first person shooter, again, just use TCP.

Otherwise you should probably look into existing game engines, which will also assist you in numerous other ways.

The latest flash has a proprietary RTMFP protocol which runs on UDP, and should handle your problem quite well. Flash has become a great platform for casual game development, and more recently even for 3D. The obvious problem is it ties your development to Adobe's whims, but it is going to save you a lot of headaches typical to non-commercial C-level game development.

[Luna]

Thanks for the replies

I am not going to convert my whole engine form c++ to uhh.. flash eww!

I already have a really nice 3d framework!
I do have UDP code working, it just lacks any sort of flow control which can lead to flooding the queue. and lack of acks, which means packets lost not recovered.

But maybe I should just send "character states" several times, like 3 times per second and if a state is lost it anyways, it won't matter much, as states would be sort of a whole thing and the game should be able to handle being without it.

Then again, I am not too sure..

[AgeVivo]

here is a tutorial example with lots of error checkings:
http://mycplus.com/s...r-and-receiver/
not sure it answers your question

is the game linked to anti-aging?

[Luna]

Thanks AgeVivo, but it doesn't help, it is just basic how to connect and send basic data (which I think is also silly because UDP is not supposed to form a connection).

I already have this working, the problem is setting acknowledgement packets and flow control systems.

As for the game, I suggested to brokenportal to maybe do something for imminst, but ideas are needed!

[AgeVivo]

Uh I don't even know what "setting acknowledgement packets and flow control systems" means ;-)
Here are ideas as they come, without synthesis, if it doesn't really make sense perhaps it'll help think of better ideas:
- sthg similar to Re-mission-life : a game to learn/share science against aging
- sthg similar to Superstruct : multiplayer game to imagine the consequences of leaving much longer
- MPrize @home community strategy: one computer randomly decides a rule for lifespan (T= a*mood^2+b*exercise-c*sugar^d-d*meat+e*sin(methylene blue) etc) and everyone can do (simulate) lifespan tests on mice with what you want. The goal is to multiply lifespan by say 3 as fast as possible, so everyone has to try to be aware of what others do, in order to be as much complementary as possible/convince what he detects as a hidden rule. It might not be obvious to find: say we have maximum 15 mice per virtual year and per person. When using few animals in an experiment, the result is statistically very poor so one might be convinced by smthg that is bad. Also, a flu might come and change the result of the experiment. If you want a mini explanation for how to randomly generate such a rule and such statistics i can detail
- an anti-aging allocation voting game : take the list of LEEEP projects, allow people to add projects/questions such as FlyPrize or not, and make everyone vote for priorities and allocate time is one/some but not all projects

Edited by AgeVivo, 11 March 2009 - 10:04 PM.

[Luna]

Some good ideas!
I think I like the MPrize one quite a bit but as you know, it can't be "too precise", as it is still just quite a low level computer simulation.
So it needs to work on certain variables and conditions (with possibilities for random values and events)

[Brainbox]

Transmitting states in stead of events could maybe help. This way, the receiver could be made tolerant towards missing a (UDP) message. It should however have the ability to deduce at some level what to do if a new state is received wrt. the current state it has. I.e. the knowledge that it apparently skipped a state and what it should do to compensate. On the other hand, missing events are very difficult to compensate for.

Or to make it stateless, but that's not going to solve it entirely and also it depends on the function behind it if this is possible at all. E.g. if you're sending movements, skipping a position message is probably not going to hurt, a typical stateless function. In addition you could send an additional movement vector with direction and speed, so that the receiver is able to extrapolate if after some time it did not receive a new position, but in that case positions should also be transmitted when the subject stands still just to be able to detect that. You will get jerky movements anyway if position messages are missing, it's just to find a way to minimise the impact. Anyway, just an example of how you could deal with missing messages.

If you're programming for a local network, I wouldn't worry to much about loosing UDP frames, especially in a stateless logic. On the internet, I don't know for sure; maybe it's possible to find some statistics on that somewhere so you know what level of loosing data you should anticipate. Anyway, in both cases you should be defensive against loosing messages in a state transition kind of logic, especially if the game is going to lock-up or behave erroneously due the the even rare event of losing a message.

Edited by Brainbox, 12 March 2009 - 06:23 AM.

[Luna]

The way I am doing it for now is sending the 3d position, rotation and a movement bit flag (stating which movements are active).
As well as an action state (what is the entity doing)

Although I am afraid it might cause skipping of action states at times.

The local users keep moving in the direction and speed their entity has, as in dead reckoning, until given a new packet from the server to adjust them, so lag and packet loss might cause jittering (which is possibly hidable with some algorithm), but as I said the problem is mostly action states.

[Brainbox]

Regarding the action states, you could think of sending these repetitively, regardles change, e.g. once a second or lower time interval. Or use a tcp connection for these things in combination with the udp for movement. Personally I think repetitive sending over udp could be tried first. This would also allow you to add timestamps to detect changes in transmission time. Clock synchronisation is an issue if you do that, but with unsynchronised network nodes you could get an idea about transmission time changes and based on that add an extrapolation already directly after receiving a position. A repetitive pace of messages could also act like a keep alive or crash detection mechanism. It has a lot of advantages. But, if not needed, the added complexity will only increase probability of bugs.

Edit: Btw., do not use flow control if you send repetitively or using udp in general. It probably will only add more delay without solving anything useful and will negate the advantages of using udp. If you really need flow control you need tcp.

If you want to read about the way these kind of problems are dealt with in professional systems, just take a look at the OMG DDS standard. This basically is a real-time databus and database with a publish - subscribe mechanism that is intended as a middleware layer for real-time sharing and distribution of data. Especially the way levels of QoS (Quality of Service) is defined and handled in this standard could be of interest (and provide some idea's on how to configure your communication channels). And maybe it could provide some more idea's how to solve things. The standard itself is quite complex, so probably not suitable (and to expensive) for your game. But they invented the wheel you are inventing right now.

Some links:
general: http://portals.omg.org/dds
QoS presentation (gets interesting at page 8 or something) http://www.omg.org/n...D/05-1_Hunt.pdf

Good luck!

Edited by Brainbox, 12 March 2009 - 08:29 PM.

[Luna]

Thanks Brainbox!

I am already sending the data regularly, the problem is with action states that might switch fast.

[Brainbox]

Ok, I must be a kid that doesn't read well.

Anyway, would it be bad if you skipped one quick state occasionally? If the gamer presses and releases a button quickly and nothing happens, he will press again and might probably think that he didn't press good enough the first time if this happens only occasionally. If it's a toggle button (quick press for activating something and after a longer while a quick press to deactivate it) you could probably design a state locally that starts after the first press and releases after the second before transmitting. That way you could avoid sending states that have a very short lifetime.

[Luna]

umm this is exactly why I want acks somehow.
About flow control, I don't want to implement it like TCP does (waiting for packets), I just want it to prevent sending too many packets in a short time, therefore flooding the server/client, causing router to be overloaded and slowing the internet terribly.

In the first days I tried UDP I made the mistake of sending a packet every frame, which causes things to update only after several seconds because of overflowing queue on the router.

[Brainbox]

If you would send a continuous stream of udp packets, bi-directional, what would be the maximum repetition time you could reach? How would this time be related to the reaction time of the gamer?

[Luna]

Uhh sorry but that sentence completely confused me.

[Brainbox]

Sorry. What I was thinking is that in stead of using the frame rate as reference, you could use the reaction time of the gamer as reference for the pace of the packets.
If you do a measurement of the maximum packet rate that is achievable and if that is well below the human reaction time, you could think of sending states and positions to the other side and the other side could "reflect" the states (and maybe positions) back so that you are able to tell if the information is complete / consistent at both sides. This way you could build a "replicator" or "mirror" of positions and states in stead of worrying about ack's at communication level. This way you would be able to use the advantages of udp and still know if the data is consistent.

Edit: Btw., to realise something like that, you could set-up a repetitive timer of maybe 200 to 500 miliseconds that triggers the pace of the udp messages in stead of using the frame rate.

Edited by Brainbox, 14 March 2009 - 12:11 PM.

[Luna]

Thanks again that is what I did last time, a timer of one second / 4.

Btw here is a video from the world editor we made

Edited by Winterbreeze, 17 March 2009 - 04:54 PM.

[Brainbox]

Cool!