[ENet-discuss] Sending big reliable message

[Doug Warren]

enet_host_service has a built in timeout if no packets are received.  By
only calling it every 20ms you are introducing a fair amount of latency
into the processing of the packets.  What I had best luck doing is running
it enet on a background thread with an incoming/outgoing queue of messages
to/from the main threads with a 10ms timeout in enet_host_service,
something like:

static int SERVER_UPDATE_TIMER = 10;


    while (!_serverClosed && ((result = enet_host_service(_enetHost,
&event, SERVER_UPDATE_TIMER)) >= 0))
    {
        // Process event
        ...
        // Process outgoing events
        while(outgoingQueue.getNext(outEvent))
        {
            ...
        }

    }



On Tue, Apr 30, 2013 at 5:29 AM, Sebastien Robillard <
s.robillard at trio-tech.com> wrote:

> I am using enet 1.3.3 and I have an issue that might be related to enet. I
> am sending a reliable packet of about 3.5 mb over a local network and it
> takes approximately 8 seconds to receive it, which I believe should be much
> faster. I have a few questions on how enet handles these packets.
>
> 1. Do the frequency of the call to enet_host_service (on either the sender
> or receiver end) matters for the time it takes to transfer the packet ?
> 2. If so, would it change something if I call enet_host_service with a
> timeout ? Currently I have a timeout of 0, and move on if there are no
> events. enet_host_service is called every frame (~20 ms)
> 3. Can we play with packet or buffer sizes in the enet library to improve
> the speed in my specific case ? I'm looking at defines like
> ENET_HOST_RECEIVE_BUFFER_SIZE or ENET_HOST_SEND_BUFFER_SIZE
>
> Thanks,
> Sebastien
> ______________________________**_________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20130430/b7add031/attachment.html>