[ENet-discuss] ENet ain't what it could be, Was: ENET_EVENT_TYPE_DISCONNECT with peer address == 0 + additional questions

[Lee Salzman]

ENet can handle that, but if your data is pretty much all reliable, just 
going straight TCP may be the best option. Then again, I've never really 
compared latency between ENet and TCP, so I can't say for sure.

ENet just really shines when you start moving to unreliable data, which 
is what it's designed for.

Lee

Intripoon wrote:
> Hi !
> 
> Basically I want it to send a rather large packet, still < 1MB, after
> connection of a client reliably and then continue sending small packets of a
> few bytes, but still mostly reliable packets with hopefully low latency.
> This is basically the scenario of a strategy game. Player connects and gets
> send the current game state. Afterwards, all player input gets send to every
> client reliably. So the networking bandwidth doesn't limit the number of
> objects to sync. Is enet suitable for this or not?
> 
> Best regards
> 	Marc
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
> Im Auftrag von Lee Salzman
> Gesendet: Mittwoch, 5. Juli 2006 16:16
> An: Discussion of the ENet library
> Betreff: Re: [ENet-discuss] ENet ain't what it could be, Was:
> ENET_EVENT_TYPE_DISCONNECT with peer address == 0 + additional questions
> 
> ENet is optimized to push packets fast. This is unfortunately not the same
> as being optimized for sending lots of reliable data. Meaning it may just
> overload your link pretty easily and start running into starvation issues if
> you start pretend its TCP with multiple clients. 
> For the occasional reliable sends, it works fine and with fairly low
> latency, though.
> 
> Lee
> 
> Intripoon wrote:
> 
>>Hi !
>>
>>I think the true solution for the disconnection waiting issue, without any
>>detailed reasons or something, is to wait until all outgoing packets are
>>sent and, while waiting, ignore all incoming packets. Then disconnect. But
>>that's easy to add on top of enet. I just wanted to make sure that the
>>current behaviour is the one how enet is wanted to behave before I
> 
> implement
> 
>>what already might meant to be there.
>>
>>I made a few more tests with more than one peer and while one large send
>>between two peers blocks all channels, sending packets to other peers
>>meanwhile works. The blocking issue could also be dealt with on top of
> 
> enet:
> 
>>Just split large packets into smaller ones, put them into a priority queue
>>and merge them back correctly on receive. Something like that is probably
>>done by enet anyways, so this might be called a bad workaround. But if
>>inserting this in enet means to break it because of complexity, I'ld
> 
> prefer
> 
>>the "workaround".
>>
>>While you say enet is not optimized for lots of reliable data, in my test
> 
> it
> 
>>still performs better than other libs. E.g. sending 10MB of data with enet
>>reliable on a 100MBit lan transferes the data at something around 6MB/s.
> 
> The
> 
>>overhead is around 1MB, so actually 11MB got transfered. If this is
> 
> because
> 
>>of resend of data or just udp overhead, I don't know. Trying the same with
>>raknet gives me 250kB/s and an overhead of 3MB...
>>
>>Best regards
>>	Marc
>>