Hi all, Emmanuel it sounds good to try to optimize the bandwidth this way, but there are some things you may want to avoid. - flushing after every send doesnt mean you'll send only 1 message, as some may need to be resent. - sending 1 message per packet is bandwidth consuming because of UDP header. Concatenation is usually a good practice.
regards, Ju On Thu, May 24, 2012 at 9:32 PM, Lee Salzman <[email protected]> wrote: > Oh, damn, I'm going senile at 30. You reminded me why it is necessary, and > I implemented it this way for this reason. Stupid brain. :( Multiple > independent connections from the same host. Forget any sort of silly > NAT/router trickiness. It's pretty stupid simple: > > If one host opens more than 1 connection to another host, there will be > multiple peers with the same IP/port. The only way to differentiate them is > with a peer id. > > So we can summarize and say that the peer id field is a feature, not a > bug. > > In my defense, I did write the initial implementation of this 10 years > ago, so the exact reasons I did some things can require some brain > excavation. :) > > On Thu, May 24, 2012 at 5:57 AM, Soren Dreijer <[email protected]>wrote: > >> Just to chime in on this a bit:**** >> >> ** ** >> >> I believe having the peer ID explicitly in the header also allows >> multiple connections between nodes.**** >> >> ** ** >> >> For instance, when I do NAT traversal, a peer attempts to connect to a >> remote peer both on the LAN address (e.g. 10.0.0.3) and via the public IP >> (e.g. 1.2.3.4). If the two peers happen to be on the same network, I’ve >> seen routers change the datagram header’s IP source for the public IP >> packet to the local IP. So, when the remote peer receives the two UDP >> packets, it looks like they’re coming from the same source (e.g. 10.0.0.2) >> even though they’re actually two independent connections.**** >> >> ** ** >> >> Enet needs the peer ID in its header to properly figure out that it’s two >> separate enet channels because the IP/host pair isn’t enough.**** >> >> ** ** >> >> Just my experience.**** >> >> ** ** >> >> / Soren**** >> >> ** ** >> >> *From:* [email protected] [mailto: >> [email protected]] *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:**** >> >> ** ** >> >> 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 sends a re-connect packet containing the long-form session >> id. So once the other end gets this, it uses the IP and session id to >> locate the correct peer, and set it up on the new port.**** >> >> ** ** >> >> But that only solves some of the problem. You still have to figure out >> what to do about protocol compatibility across all users of ENet... >> Trickier problem. :)**** >> >> ** ** >> >> On Thu, May 24, 2012 at 4:31 AM, Len Holgate <[email protected]> >> wrote:**** >> >> > 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 is running.**** >> >> >> > Anyway, I'll do a loose bind then, ie: if there's no perfect IP / >> > Port match, I'd do only a IP match, that should be ok in my case.**** >> >> Which will work just fine if you only have one peer coming in from that >> particular address... >> >> Len >> www.serverframework.com**** >> >> >> > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
