[ENet-discuss] Large data packets over ENet
Jacco Bikker
jacco.bikker at overloaded.com
Wed Feb 2 11:28:21 PST 2005
I know what you mean, but I tried TCP, and it doesn't work for me. The
problem is the latency: Ideally, I want to connect 16 or more computers.
This would allow me to render 1024x768 @ 25fps or faster. The size of the
transfer would indeed justify TCP, but the desired speed makes this a less
optimal choice. I heard that there's a protocol for streaming video; that
might be something to check out. In my case, it's not a big problem when I
miss a packet; it would mean that some display lines don't get updated for
one frame. But speed is essential.
> If you try to use ENet like TCP (which you are), performance is going to
> suck. ENet
> is simply not made to transfer large streams of bulk data as efficiently
> as possible, but
> is instead optimized to transfer lots of little packets with as low
> latency as possible.
> Totally different focus.
>
> Lee
>
> Jacco Bikker wrote:
>
>> Couldn’t you look at the client-server model like this: The server is
>> the ‘managing’ system that distributes data to all clients. In that
>> case, it’s not strange to call the rendering system ‘server’. In fact,
>> this system will also handle user interaction and so on, so it’s
>> definitely the system that knows most about the process. Perhaps
>> ‘master-slave’ is better, like in OpenMPI.
>>
>> Data transfer rates: It’s 768KB raw data indeed, and it gets
>> compressed (using LZO) to about 1/6^th of that (lossless, there are
>> quite some black areas in the sample scene I’m using). That’s still
>> more than 100KB per frame, so at 20fps, it’s 2MB. The network should
>> be able to handle that, but ENet isn’t: Performance drops to 400ms per
>> frame where I achieved 200ms or less in the original application (no
>> client-server rendering), or 240 in my first (buggy) UDP/Winsock
>> implementation with LZO compression. For comparison: Last night I
>> tried RakNet, which manages to get 270ms frames (also using LZO
>> compression), which isn’t optimal, but pretty close.
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
More information about the ENet-discuss
mailing list