ddlox said:

Let's say if u were getting 25 udp packets per second in a 25FPS scenario:

(P1, P2, P3,….. P10, P11, P13, P15, P12, P14 …. P20, P21, P23, P24, P25) per second:

• if your app processes 25packets after each second, then all u need to do is sort this list every second and process them
• if your app processes each packet as they arrive then depending on what your app's use-case is trying to achieve:
  • UC1: when u receive P13 after P11, u can process P13, but when P12 arrives just discard it
  • UC2: when u receive P13 after P11, u can hold P13, and wait for N packets in hope of receiving P12, if it arrives within N packets then process P12, P13 etc… if it doesn't arrive then process P13 (discard P12 whenever it arrives in the future). Same deal for P15 (waiting for P14)
  • UC3: when u receive P13 after P11, you can time the arrival of each packet, so if for ex P12 within the next 40ms then process P13 and discard P12 when it arrives in the future
  • etc…
• etc…

point being, it is your responsibility to establish some rules for your incoming data packets; and if your packets have no inter-related dependency then the easier the decision;

For example:

• Case A: a player increasing her car speed: these packets would contain current incremental velocity/accelaration values of speed
• Case B: a player teleporting to various places: these packets would contain the current positional values (as opposed to incremental) of location

Case A could be treated with UC1, UC2 or UC3, whereas case B would be treated with UC1 only (ideally)

so it's all in your hands ;-)

@ddlox Thanks alot for those use-cases ! in your experience is it true that the packet reordering isnt all over the place but that its within X packets and not ex between 100 packets ( so you expect ex packet no 2 but get packet 100 ) ? i would probably be looking at UC3 but will start from UC1 and see how it goes but probably end down in a compliacted rabbithole with UC2 or UC3 ?

Quote: In general, though, if you're prepared to “wait a little bit” after receipt, you should probably just use TCP.

That is a fair point;

i guess my use-cases covered the aspect of “wait a little bit and/or accept packet loss”, in which case UDP is still just fine; if packet loss is unacceptable then TCP should be used..

joopyM said:
…( so you expect ex packet no 2 but get packet 100 ) ?

in my experience, it has been within short distances between packets indeed, i have not experienced far distances packet reordering… (not to say that it doesn't happen) ;-)

joopyM said:
i would probably be looking at UC3 but will start from UC1 and see how it goes but probably end down in a compliacted rabbithole with UC2 or UC3 ?

yes that's how you grow your experience, the white rabbit told me everything when i was in there -lool-

All the best ;-)

@taby @hplus0603

TCP is out of the question as i dont need the reliability and previous tests with TCP is fine - until it goes bad then the effort from TCP to ensure reliabillity is causing some very noticeable and annoying delays, will use TCP for control channels where its neccesary to ensure data is going back and forth but for the live-action UDP is alright as packets-in-the-past ( to a certain degree ) is outdated anyways so i dont need to get all these ensured.

So its only UDP related and for now i do not think i would need to go for reliabillty (RUDP) but even if you went for RUDP then in theory ( probably hard to make good ) you could make other models for reliabilty than TCP where you can say you maybe only want partial reliabillity while it would probably be tough coding i can see some ideas you could implement that could give you some kind of reliable transport but not 100% reliable which you cant tune on TCP.

And the sequence approach and packet-ordering is just about ordering the incoming packets there still isnt any ACK/NAK implemented in this model which you would have in TCP - you are right with packetsizes etc but i plan to be below 1450 bytes per packet - so this is only UDP related, TCP is not an option for this task also due to the realtime aspect of it.

@ddlox

edit : can see my other reply was posted already and you replied that - thanks alot ?

ddlox said:

Quote: In general, though, if you're prepared to “wait a little bit” after receipt, you should probably just use TCP.

That is a fair point;

i guess my use-cases covered the aspect of “wait a little bit and/or accept packet loss”, in which case UDP is still just fine; if packet loss is unacceptable then TCP should be used..

yes if packetloss is unacceptable then its TCP ( or RUDP but then most likely better go for TCP ) - but packetloss is acceptable to a certain degree from the point of view that the latest packet-sequences are important and old packets arent really important as they are in the past - but the order is important so ex if it was X, Y coordinates - then i cant ‘play’ packet 100 and then play packet 1 and then play packet 50 and then packet 3 - that would look quite odd ?

One usual metric for estimating this is the bandwidth delay product. Practically, the longest reordering that can happen is the sum of all buffering and transmission lines between source and destination. For packet-based networks (like UDP,) you're generally better off with less buffering, so you'll want to keep the kernel buffer in the sending server outgoing side not too big (say, 20 milliseconds per player times packet stream size per player.)

It's not really possible for the network to “re-order” more than it buffers, because once a buffer fills up, packets have to be discarded.

But, evenso, you should be prepared to discard some packets as “too old” no matter what – at some point, you've “waited enough.”