...@cubik.org [mailto:
enet-discuss-boun...@cubik.org] *On Behalf Of *Lee Salzman
*Sent:* Thursday, May 24, 2012 6:53 AM
*To:* Discussion of the ENet library
*Subject:* Re: [ENet-discuss] Optimizing ENet Protocol ?
** **
One way to handle all the mess reliably that I could conceive
Hello,
I have been using DirectPlay from DirectX9 since 6 years in my games
and have been pretty happy with it since then, except I cannot use it
on Mac OSX.
So I've decided to give Enet a try and I just had a deep look at
Protocol.c .h .
DirectPlay gives a packet overhead of 4 bytes for
Hello Emmanuel,
Interesting thoughts! I'm not worried at all about the overhead in ENet,
but things like peerID have caught my attention earlier as I didn't
understand why it was there.
I still don't understand why it's there as (like you said) we could just
map each Peer to the source
On Thu, May 24, 2012 at 2:48 AM, Emmanuel Rivoire manu@laposte.netwrote:
Hello,
I have been using DirectPlay from DirectX9 since 6 years in my games and
have been pretty happy with it since then, except I cannot use it on Mac
OSX.
So I've decided to give Enet a try and I just had a
Does the UDP packet's header contain the port of the Router or the
initial sender port ? I'd guess the later, as when you send some
The datagram can only contain the address and port of the sender. BUT the
sender, in the case of NAT routers, is the NAT and NOT the client machine
where your code
On Thu, May 24, 2012 at 4:42 AM, Emmanuel Rivoire manu@laposte.netwrote:
Hello,
At 18:05 24/05/2012, you wrote:
The length is needed because ENet does all sorts of aggregation. The
packet boundaries are not 1:1. If you have 10 ENet packets in one UDP
protocol packet, well, there's no
One way to handle all the mess reliably that I could conceive:
Hash on IP/port, just a big linearly probed array of pointers to peers
would be sufficient. If not found, then send a sort of ack back to the
client, requesting a re-connect packet. Once the other side receives the
ack, that side
Of Lee Salzman
Sent: Thursday, May 24, 2012 6:53 AM
To: Discussion of the ENet library
Subject: Re: [ENet-discuss] Optimizing ENet Protocol ?
One way to handle all the mess reliably that I could conceive:
Hash on IP/port, just a big linearly probed array of pointers to peers would
On Thu, May 24, 2012 at 5:47 AM, manu.n02 manu@laposte.net wrote:
I assure you, packets are aggregated, even unsequenced ones.
Oh, yup, I found it, there's a while (currentData host -
receivedData [host - receivedDataLength]) in
enet_protocol_handle_incoming_commands() ..!
But if I
library
*Subject:* Re: [ENet-discuss] Optimizing ENet Protocol ?
** **
One way to handle all the mess reliably that I could conceive:
** **
Hash on IP/port, just a big linearly probed array of pointers to peers
would be sufficient. If not found, then send a sort of ack back
10 matches
Mail list logo
