https://github.com/jivibounty/Packet

This is a free open source C++ UDP networking library with reliability built over udp specifically for fast paced games. I just thought I should share it with anyone interested. Use at your own risk.

I'll probably go with Boost::Asio if i need one, cos it is opensourced and has wide developer community......

Jivi:

https://github.com/jivibounty/Packet

This is a free open source C++ UDP networking library with reliability built over udp specifically for fast paced games. I just thought I should share it with anyone interested. Use at your own risk.

Hi, that's interesting.
How did you implement the reliability feature? I went through the code a bit, considering the way the server is started, shouldn't you be getting text data from the Application layer and not binary packets? The code seems to be working with packets.

Neat code by the way.

lordZOUGA:

Hi, that's interesting.
How did you implement the reliability feature? I went through the code a bit, considering the way the server is started, shouldn't you be getting text data from the Application layer and not binary packets? The code seems to be working with packets.

Neat code by the way.

For reliability, when packets are sent they are given a unique sequence number and stored in an stl map data structure using the sequence number as the key. If the packets arrive at the destination, an ack is reqistered for the packet using the sequence number in order to prevent multiple reception of the same message or to ensure that the message is only received once and an ack message is sent back to the sender which then deletes the reliable packet from the map and stops sending packets. If an ack is not received by the sender, it sends the same packet on each update from the ones stored until the reliable packet times out.
You should be able to send both text and binary data or maybe I dont fully understand your second question though.

Jivi:


For reliability, when packets are sent they are given a unique sequence number and stored in an stl map data structure using the sequence number as the key. If the packets arrive at the destination, an ack is reqistered for the packet using the sequence number in order to prevent multiple reception of the same message or to ensure that the message is only received once and an ack message is sent back to the sender which then deletes the reliable packet from the map and stops sending packets. If an ack is not received by the sender, it sends the same packet on each update from the ones stored until the reliable packet times out.
You should be able to send both text and binary data or maybe I dont fully understand your second question though.

Okay. That's like turning UDP into TCP. yes?

Doesn't that slow down the UDP connection and makes it a bit unpredictable? considering that UDP's usefulness lies in its unreliability.

I mean if I am playing FIFA and the ball is in an opponent's goal post and the packet with the ball's position gets dropped due to bad connection or something. On a normal UDP connection, this wouldn't matter as the gamer would just see a drop in frame rate or a lag in game play but using this library, the packet with the ball's position will probably return slower than usual, or make the game run at different speeds for the gamers or crash the game? is that possible?

My previous question was how do you get all the outgoing/incoming Udp packets with your library?

lordZOUGA:

Okay. That's like turning UDP into TCP. yes?

Doesn't that slow down the UDP connection and makes it a bit unpredictable? considering that UDP's usefulness lies in its unreliability.

I mean if I am playing FIFA and the ball is in an opponent's goal post and the packet with the ball's position gets dropped due to bad connection or something. On a normal UDP connection, this wouldn't matter as the gamer would just see a drop in frame rate or a lag in game play but using this library, the packet with the ball's position will probably return slower than usual, or make the game run at different speeds for the gamers or crash the game? is that possible?

My previous question was how do you get all the outgoing/incoming Udp packets with your library?

It is not the same as turning UDP into TCP. Using TCP, if one sends a packet A and then another packet B in turn. B has to wait for A to be sent and acknowledged before B gets sent across the network but using Reliable UDP, A and B gets sent immediately without any one waiting for the other. Also, there is an API for sending the packets unreliably.

Using your FIFA example, most messages would be sent unreliably but there are some messages that have to be sent reliably and those ones get to use the reliable sending path for example, goal scored message.

You use sendPacket API to send data unreliably, sendReliablePacket to send data reliably and receivePacket to receive data. Each of these methods are in the UdpServer and UdpClient classes.

Jivi:


It is not the same as turning UDP into TCP. Using TCP, if one sends a packet A and then another packet B in turn. B has to wait for A to be sent and acknowledged before B gets sent across the network but using Reliable UDP, A and B gets sent immediately without any one waiting for the other. Also, there is an API for sending the packets unreliably.

No, that's not really how TCP works.

Jivi:


It is not the same as turning UDP into TCP. Using TCP, if one sends a packet A and then another packet B in turn. B has to wait for A to be sent and acknowledged before B gets sent across the network but using Reliable UDP, A and B gets sent immediately without any one waiting for the other. Also, there is an API for sending the packets unreliably.

Using your FIFA example, most messages would be sent unreliably but there are some messages that have to be sent reliably and those ones get to use the reliable sending path for example, goal scored message.

You use sendPacket API to send data unreliably, sendReliablePacket to send data reliably and receivePacket to receive data. Each of these methods are in the UdpServer and UdpClient classes.

I don't think UDP has a "reliable sending path". You basically send a message and hope it gets to your destination.

Your description of TCP isn't true, each packet is given a sequence number and sent. The endpoint is responsible for verifying them with their checksum and sequence number and putting them in order. When a handshake is needed is in connection initiation.

There is also a risk of timeouts, since the kernel isn't aware of the program proxying the packets, it will also attempt to resend packets it previously sent (the same packets this program has cached and is trying to send reliably). This might cause multiple responses for the same command and slow down connection.

If you wish to publish a library. A good documentation and well commented code is just as important as your code base. Without those, you will find that at best case few will use and in most cases, no one will.

lordZOUGA:

I don't think UDP has a "reliable sending path". You basically send a message and hope it gets to your destination.

Your description of TCP isn't true, each packet is given a sequence number and sent. The endpoint is responsible for verifying them with their checksum and sequence number and putting them in order. When a handshake is needed is in connection initiation.

There is also a risk of timeouts, since the kernel isn't aware of the program proxying the packets, it will also attempt to resend packets it previously sent (the same packets this program has cached and is trying to send reliably). This might cause multiple responses for the same command and slow down connection.

By UDP reliable sending path, i do not mean that UDP on its own has a reliable sending path
but rather that the library on github has APIs for sending both reliably and unreliably on UDP.

Also, based on TCP, the main point is an older packet blocks the newer one in the work flow causing a delay.

Building reliability over the UDP will make it slower than just UDP but always faster than TCP provided order is not enforced.
The packets has sequence numbers that prevents it from being received more than once.
So, if it has being received before, it checks for another message instead.