[ENet-discuss] roundTripTimeoutLimit with big ENET_PEER_TIMEOUT_LIMIT

[Uj]

Well it's your application do decide if the disconnection is sudden...
(expect for crashes of course, but your app shouldn't crash ^^)
I can't see Alain the difference in your case between disconnection and
timeout actually... timeout causes disconnection.

If those settings are for debugging purposes, then take them off in the
release version and it should be fine :p

If you can spot the moments when you need high timeout,
then set them dynamically and adjust them when needed.
Or use specific messages to prevent specific situations (like asserts or so
on).

Hope this helps,
regards,
Ju


On Thu, Nov 5, 2009 at 7:51 PM, Alain Becam <Al at thegiantball.com> wrote:

> Indeed...
>
> 2009/11/5 Nuno Silva <little.coding.fox at gmail.com>
>
> Not to mention you'd have the same issue if the users' network was
>> disconnected suddently.
>>
>> On Thu, Nov 5, 2009 at 5:27 PM, Alain Becam <Al at thegiantball.com> wrote:
>>
>>> Hi,
>>>
>>>    Thank you for your answer! Actually when they disconnect properly, there is no problem. It is in case of crash that we have this problem. Unfortunately it happens ;)
>>>
>>> //Alain
>>>
>>> Hi Alain,
>>>
>>> Is it possible for your peers to send a disconnection message before going
>>> away ?
>>>
>>> regards,
>>> Ju
>>>
>>>
>>> On Thu, Nov 5, 2009 at 2:03 PM, Alain Becam <Al at thegiantball.com <http://lists.cubik.org/mailman/listinfo/enet-discuss>> wrote:
>>>
>>> >* Hello,*
>>> >*      Greetings from a new happy user. We are using ENet has the "low-level"*>* communication API for an object-oriented solution, with object replication.*>* Thanks for this great library !*>**>* Mostly for debug purposes, we increased the TIME_OUT, like that:*>**>*    ENET_PEER_TIMEOUT_LIMIT                = 3200, // 32*>*    ENET_PEER_TIMEOUT_MINIMUM              = 5000, // 5000*>*    ENET_PEER_TIMEOUT_MAXIMUM              = 300000, // 30000*>**>* It works well to avoid too quick disconnections, but we still have a*>* problem. When a new peer connect, it receives the list of existing peers*>* from the server, then try to connect to all peers, and when done, send an*>* acknowledgment to the server. Then the server replicates the existing*>* objects. But with these time-out, a disconnected peer is discovered after a*>* very long time, and if a new peer connect, it will never send the ack to the*>* server (because he is waiting for the connection and until it receives the*>* disconnection event).*>**>* We tried to do that in protocol.c (line 1270):*>**>* outgoingCommand -> roundTripTimeoutLimit = (ENET_PEER_TIMEOUT_LIMIT/100) **>* outgoingCommand -> roundTripTimeout;*>**>* But it seems to have some nasty side-effects (when some communications are*>* occurring, it might disconnect very quickly again)...*>**>* Any way to have a quick disconnection and still a long time-out for comms ?*>**>* Kind regards,*>*     Alain*>**
>>> >* _______________________________________________*>* 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*>**>**
>>>
>>>
>>>
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>>
>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>
>>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20091106/9c9da334/attachment.htm>