Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

100 Neutral

About Pfaeff

  • Rank
  1. Pfaeff

    Reliable UDP and packet order

    I already did that, but when I was finished with the system based on TCP, I decided to try out UDP. Make a drinking animation that lasts 1 second, where health is only restored after that one second. It will cover the latency and hint player that they are vulnerable. The first packet gets lost for one client and is resent some time later.[/quote] "The packet ain't lost, it's restin'." Each action, message, command, etc... has a timestamp of sorts. Some actions, especially ones which are frequent, can be sent as "unreliable". For movement, they would arrive with following timestamps: 1,2,4,3,7,8,9,10. 3 would be discarded, since we already received 4. Packets 5 and 6 are pinnin' for the fjords, but since we received 7 and later, we don't care. Now here's a catch - what about message 11? Was it sent? Was it lost? What about 12, 13, ....? And what if now send an action message, such as picking up something - am I in range or not? [/quote] My current implementation supports unreliable messages and I plan on using them as you suggested. If the received message has an older "timestamp" as the most recently received message, the new one is simply discarded. I think the problem of packet ordering is fundamental for every game and that is why I asked for methods to deal with it. Of course there are games in which such problems are not so much apparent and there are games where those problems can be circumvented using clever design of gameplay as described in my first post or in the example of Antheus. But there might be cases in which that won't work (none that I can think of atm though). If these cases are rare and isolated, a simple stop-and-wait strategy could work. Other cases might require some resynchronisation with the server, but I am not sure if more sophisticated methods may be required for my needs.
  2. Pfaeff

    Reliable UDP and packet order

    Thanks a lot, what you're saying about resending packets sounds reasonable. I want to use UDP, because I plan on implementing some gameplay elements that require a bit more responsiveness. This project is also for me to learn some network programming, because I've never done such before. Even if UDP is overkill for my application (which might or might not be the case, but it gives me some tolerance), I will be able to apply those techniques to future projects that require a fast and responsive network system. The problem I have is the following: Let's say a player with 10 life drinks a potion at t0 and gains 10 additional life That player gets hit for -10 life at t1 The first packet gets lost for one client and is resent some time later. For him the player will get hit and die, while for all other players he will be alive. I know that this can be prevented if the server just sends the absolut life values for the players. In this case he will die either way, but a bit later for one of the players. The thing is that I am not sure if that will always work. There might be other mechanics that I didn't think of for which no such simple solution exists.
  3. Hi, I have a working basic network communication via udp for my hack&slay RPG game. I implemented reliability using acks. Messages will be resend, if the ack didn't arrive within 2*RTT. Everything seems to work pretty nicely, but there is still one problem to be solved: the case when reliable messages are received out-of-order, which will lead to inconsitencies among the players. As far as I know there are two ways to solve this problem: let all players live x ms in the past and hope that all necessary packets arrive during that time, if not, resynchronize the player, or kick him from the server do a rollback and send anti-messages for any reliable messages that where sent (those might in return trigger more anti-messages and so on) I don't like the second solution, because it is rather complicated to implement and anti-message introduce much extra traffic. So I would opt for the first method. Or are there other more suited techniques that I don't know about? Greetings, Pfaeff
  4. Are you expecting for one client to be serving multiple users? The user id can be inferred from the IP / port of the packet. Including a user identifier in packets only yields to vulnerabilities where the user id is accidentally used unverified, allowing clients to impersonate one another. [/quote] I also thought about this and I think you are right. It would be better to just identify the users based on the IP address. What would be the best approach to do that? Is there maybe a fourth alternative that I didn't think of that could solve all my problems? [/quote] If the peer records which reliable messages are associated with each packet, when a packet is acknowledged then all reliable messages that were included in this packet can be marked as delivered. [/quote] Why didn't I think about this ? The sender just needs to know which messages where in the packet that got acknowledged and mark them all as received. This seems to be the best solution. Thanks a lot.
  5. Hi, I am currently working on a network abstraction layer that will be able to deliver reliable and unreliable messages over UDP. Each UDP packet contains a user id, the current sequence number, an ACK field and an ACK bitfield (as described here) and a payload among other things like the current tick. The payload contains the games messages. Each message is simply a message type id followed by the message data. I now want to be able to send certain message reliably and unreliably, but that seems to be very tricky if I have packets that contain mixed message types, due to the fact that the ACK field refers to the packet and not to its content. Three solutions came to my mind: Send all packets reliably (most simple solution, but I am not sure how big the effect on network performance would be) Don't mix message of different reliablity type in the packets payload. Have packets that only contain reliable messages and packets that only contain unreliable messages, but let unreliable packets be able to acknowledge reliable packets. The question here would be, how frequently should reliable and unreliable messages be sent? Sometimes there might even be no reliable messages to be send, because they're only created for consistent events (in my specific use case). If I'd send let's say 20 packets per second, what percentage of those should be reliable packets that contain only reliable messages? Have a sequence number and a reliability flag for each payload and treat them like single packets, but bundle them together before sending them over the network. What would be the best approach to do that? Is there maybe a fourth alternative that I didn't think of that could solve all my problems? Thanks in advance. Greetings, Pfaeff
  6. Thanks. If the server puts its current tick count in the packets (or bundles of packets) he is sending to the client, the client can then use that count as its new tick count. This way the ticks would be synchronized, am I right? During the time the packet is traveling through the net, the server will most likely be one or two ticks ahead and that is why packets from the clients have to be forward timestamped, if I understood you correctly. What would/should happen if the server receives a packet that has a tick from the past? Is there any source where I can read more about such a system? I still don't really see the advantage of this approach towards sending the most recent data and treating it as the new world state, assuming the packets arriving in the correct order, like when using tcp, or some reliable protocoll on top of UDP. EDIT: I think the client needs to know in which tick the event occurs, because otherwise he couldn't make a local prediction as the packet he receives from the server is already in the past, but how does the server benefit from knowing at which tick the client triggered a certain event, maybe for server side prediction?
  7. I have yet to decide on a suitable simulation tick rate. I guess it should be the same for the client and the server then (GUI updates and stuff posing an exception). My netcode should already be able to bundle multiple packets before sending them through the network, but I haven't used a packet sniffer to verify that functionality, yet ;-). If I understand you correctly, what you suggest is the following (please correct me if I get this wrong): Have a fixed simulation interval on the server and the client (and perhaps a slower network tick) Count the elapsed ticks of the simulation Whenever an event occurs, create the corresponding packet and put the current (simulation) tick count in it Put that packet in a buffer When the next network tick occurs, send all the packets in that buffer (in one go) to the clients So would I have to synchronize the clocks between the server and the client? What is the client's benefit of knowing in which tick an event occured (better lag compensation I guess)? How would the client deal with those information? Thank you.
  8. The problem I have with this, is that I will have to somehow store those one time events to be able to transmit them to the clients later on. One way to do it would be to create the packets immediately and store them in some kind of buffer. The server will then send all the packets in the buffer during it's "tick" (meaning every 50ms). The threads are currently being synchronized using a queue. Every packet gets stored in this queue which is synchronized. Then it is emptied by the server's main thread and the packets are processed. This way I only have to synchronize one single object.
  9. Hi there, I am currently working on my first network-based game. The game is a real-time topdown RPG and uses a client-server architecture. The basic architecture already works and right now I am trying to figure out what the best way to synchronize the world state might be. I often read that you would have a server loop that will send world state updates every 50ms. That sounds reasonable for continuous variables like positions, but what about one time events like spawning an entity or attacking? My current idea is the following: Every time a player connects, send him the whole world state immediately. Every 50ms send an update for positions, life, mana and such things to all clients. Handle one time events (entity spawning, attacking) immediately. I am not sure if that is the right way to do it, but it would definitely be the easiest. The alternative I think would be to store those events and send them together with the current world snapshot, but I am not sure if that would be a good idea. I hope you can shed some light on this issue. Thanks a lot. Greetings, Pfaeff
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!