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

[Lee Salzman]

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
>