If you only create one UDP socket, then don''t you suffer from the fact that you only have one OS buffer on that socket?

I''ve written a completion port based thread pooling UDP class, and I''ve gone with a new socket for each connection for this reason.

As to UDP being re-inventing the wheel, it depends what you are using it for. If you have to put your own reliable layer on top then yeah it is, but at least you don''t have the exponential back off that TCP/IP has. Having said that I quite like DAoCs approach of having a TCP/IP socket for the reliable stuff and using UDP for things that are time-sensitive and non-critical (i.e. mob position update etc). That way you pretty much get the best of both worlds (although beware of issues such as sending reliable data and then refering to it in non-reliable data assuming that it will already be there).

AP, you can set the size of buffers with setsockopt. Using a seperate socket for each UDP logical connection IMHO is to take away from some of the benefits of using UDP. Since completion ports aren't portable, I usually tend to avoid using that mechanism. Many network apps use the hybrid TCP/UDP model. EQ uses it, they just don't put text out to the user saying that that is what they're doing. And very little is done via TCP. 99% of reliable communication is via UDP(reliable and unreliable both).

[edited by - fingh on July 5, 2002 1:54:16 PM]

Honestly, if you don't want to limit yourself to one UDP port, simply have it rotate between 5. It's still a LOT less than one port open per client.

I believe that Multiplayer Game Programming also has some information about building a reliable UDP layer.

Our plans for communications are very similar to what other companies are doing, with UDP handling most all communications and TCP handling attacks, combat actions and spell casting. We might not even have those handled by TCP though... there are some other options that we're considering.

[edited by - solinear on July 8, 2002 2:28:37 PM]

I''ve never done any EQ packet sniffing myself, but I did look over the source code of the two emulators and I really couldn''t see any use of TCP appart from the server negotiation stuff. Pretty much all normal data was over UDP.

Anyway guess I may revise how many sockets I use. As to completion ports being non-portable, I''m aware with that, but its a worthwhile sacrifice for me - especially in light of the performance benefits.