devhandle
commented
6 years ago I've managed to fix the client issues i was having. I had a short sleep() in my code which was causing the clients to read slowly. I've removed the sleep altogether the speed has increased massively.
I do have another issue though. As mentioned I'm broadcasting large chunks of data per second (~10Mb). I'm testing everything locally on my machine and everything works great until I connect more than 2 clients. On connecting a 3rd client I see the throughput slowing gradually and the server memory increasing until I get an OOM error. I'm guessing the server is queuing data internally but the amount of data I'm sending is still not that high. I was hoping that the number of clients would not cause an issue when I'm not using the reliable delivery behaviour.
inlife
I'm testing enet to see if it's suitable for our needs. We want to broadcast ~10Mb per second to multiple clients. Packet loss / reliability is not a priority so UDP is suitable - I chose enet because of the easy to use api.
I've created a client and server - the server continuously broadcasts packets (_enet_hostbroadcast) in a loop sending large ~2mb packets. The problem is the client is only receiving around 1 packet per second. The docs state that _enet_hostbroadcast queues the packet for sending and I can see that the server memory increasing quickly. The data is queued but isn't being sent quickly enough.
Reducing the packet size does improve things but the maximum speed I could achieve from a single server and client was around 5mb per second. This is all running on localhost on one machine. I can achieve > 90Mb per second if I use ZeroMQ (TCP)!
I've set ENET_PACKET_FLAG_UNSEQUENCED which did improve speed but I was hoping to at least match ZeroMQ speeds.
Is enet suitable for what I'm trying to achieve (continuously sending large buffers >2Mb)? Has anyone experienced such slow client speeds?