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

[Nono BEZMan]

Thanx Steve and David for your concerns.

I am developping a file transfer protocol, and 512KB
seems like a sweet spot for me to be (fragmentation-
encryption-wise, etc....)

Honestly I am having a hard time understanding what is
going on.

If I send 512KBytes packets back to back with one
peer... it is fine. If I have 50 peers sending 1KBytes
(or even less) back to back, a lot of them eventually
drop (within a minute or so). I have a 60 KBytes
upload bandwith to play with. So, logically the 1 peer
sending 512KB packets will take 10 times as long as a
peer in the 50-peer test to send its packet!!!

Also, the whole point of using enet for me is to
utilize the reliable UDP mechanism (slicing,
re-ordering, etc....). If I were to break up my
packets into piece less than 1400 (MTU for my
setting), I would then lose mopst of the benefits that
Lee already put in there for us. Also, from my
previous paragraph, it will not help much anyways.

I do think there is a weird behavior, in that some
peer seems to not be serviced, and simply lag behind
more and more until they are kicked out. This is why I
try to put randomness in the send_outgoing_command()
function, so that all peers may have a chance to be
serviced, but it did not help.

Statisticallly, all my UDP datagram have the sam
chance of being dropped (one server, one client and
all fully encrypted [enet header included]). So the
router cannot tell the difference between UDP
datagram. So statistically, the flow control should be
quite achievable in this scenario [quite ideal for
this kind of problem], and all peers should throttle
down and be serviced equally ?!?

I tried to play with the windowSize also (reduce it)
to no avail. Lee kindly replied to my email, and I
will follow up with him, as I do think solving this
issue could benefit a lot a people.... or may be I am
the only one having this issue :-(

Again, I am really open to any siggestion here,
especially if any of you have experience with high
capacity servers using enet (lots of connections). For
me, after 30 conenctions (sending 128 bytes back to
back), it breaks down.

Thanx again for your help.




--- Steve Williams <stevewilliams at kromestudios.com>
wrote:

> 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.
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around 
http://mail.yahoo.com 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com