Are you planning on adding a reliable UDP method?

I am working on a prototype for a lock-step game. The data i need to send every step is small, but it needs to be reliable. But since TCP is the only reliable method and your documentation talks about it having to buffer the packets I feel this is buffering is going to cause me problems. Is nagle's disabled?

A typical packet might contain 3-5 longs.

I am currently doing a test where I am sending packets to the server it just sends the same data back.

I have setup the clock synchronization examples and it is telling me latency of around 50-90ms.

I added a timestamp to the messages and I am seeing round trip times from 2x up to 4x or 5x latency.

2x I would be expecting, but the higher times make me wonder if there is some buffering going on when sending reliable? The same on the server, the responses are sent reliable.

Possibly, but it would require extra work on my part.

Lock-step networking just requires sending the inputs and then the simulation is run deterministic on all clients to stay in sync.

This system was typically used in RTS type of games.

All inputs must be collected and processed every turn or clients will become out of sync.

I would have to basically implement my own reliable udp on top of your udp by acking recieved packets, and re-sending until i get the ack etc.

I know other network providers like Photon offer reliable UDP options.

http://forum.photonengine.com/discussion/1858/udp-vs-tcp-for-non-realtime

https://doc.photonengine.com/en-us/onpremise/current/reference/binary-protocol

There are various places talking about it just by searching.

This functionality can be replicated but in Unity where multithreading is can be a pain.

It would be nice if the SDK say in its networking thread could handle the ACK and Resend logic automatically.

So that simple processing could not have to take place on unity's main thread.