[ENet-discuss] Peer starving problem....

[Steve Williams]

I think it's worse than that.  He was talking kilobytes(KB), not 
kilobits(Kb).  At the end of his post, he states that they are maxing 
out their outbound connection at 50KB.  I believe this will probably be 
a 512Kbps connection.  So you're probably looking at 15-20 seconds to 
send a 512KB packet per peer.

-- 
Sly


David L. Koenig wrote:

>It sounds to me like the host is running out of outgoing bandwidth.  
>Most DSL connections give you about 128Kbps outgoing, 768Kbps to 3Mbps 
>incoming. 512k is 4 times the outgoing max. So, under the best 
>conditions you can hope to have the packet go through to the/from the 
>server in four seconds. That will never happen as enet is going to have 
>to break up the packets into chunks of around 1500 bytes which is a 
>standard MTU limit, so you lose some bytes to overhead.   It's so backed 
>up with outgoing packets that it can't possibly send them all within the 
>connection timeout limit. You want to try to limit your packet size to 
>1500 including any overhead (UDP header overhead, enet overhead).
>
>Exactly what sort of data is it that you're trying to send?  Why must 
>the packet be so large?  Do you know the upload/download speed provided 
>to your server?
>
>-dave
>
>Nono BEZMan wrote:
>  
>
>>Hi all,
>>
>>I have used enet for a while now, and we just came
>>across this issue which we could not resolve:
>>
>>- Setup: we have one client talking to one server
>>(enet_host_service every 20 ms) on a DSL connection.
>>
>>- Test1: client send packets of 512KB to server back
>>to back, using only one peer. Everything goes fine.
>>
>>- Test2: client sends packets of 512KB on more than
>>one peer (2-3 in general). All peers are disconnected
>>after one minute or so, but one which goes on once it
>>"killed" the other ones.
>>
>>We have also tried to send 4kB (or 2KB) packets with
>>50 peers at the same time.... at the end most "starved
>>to disconnection", except for a few ones (like a
>>dozen) which then went on happily forever. The bigger
>>the packet, the less peer at the end of the fight.
>>With 1K packets we ended up with ~20 peers, with 2KB
>>about 12 peers and with 4KB we had ~6 peers still
>>going at the end.
>>
>>We even tried to randomize the order in which the
>>peers where serviced in send_outgoing_commands to no
>>avail.
>>
>>It is very puzzling to me, as enet being UDP based, I
>>do not see why peers starve to death after some point.
>>Sending 512KB packets back to back (and maxing our
>>upload connection at 50kKB) works fine until we add a
>>second peer....
>>
>>We tried Enet 1.0 (latest CVS) as well as previous
>>versions of Enet.
>>
>>Anybody would have any ideas/pointer on how to resolve
>>that issue?
>>
>>Thank you,
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam?  Yahoo! Mail has the best spam protection around 
>>http://mail.yahoo.com 
>>_______________________________________________
>>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
>
>
>  
>


-- 
Sly



This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.