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

[Intripoon]

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