I''ve teamed up with some colleagues to add multiplayer support to a program of theirs. Eventually, I want to design a massive multiplayer game, using a persistent world (many servers, many clients, one world). Should I bother with DirectPlay, as eventually I suppose my servers will be Unix based. Also, is programming a networking class for Winsock THAT MUCH more complicated than DirectPlay? I know Directplay has many routines built in for creating/joining sessions, messaging, blah blah blah, but if I learn the DirectPlay API, its useless when I begin thinking cross-platform. Is Winsock the way to go then? Julian Green Toronto, Canada

Well if your servers are gonna be unix based then go with winsock. I''d go with winsock either way since it''s pretty easy. (in a custom control ) I think you can steal a C++ winsock class from the GDTalker SDK. Just ask The Senshi and he''ll give you a copy.

---------------------------
www.bountyhunterinc.com t-shirts for the morally impaired.

For massively multiplayer programming I would go with sockets. They are EASY to port from Windows to UNIX and offer immense control.

The MSDN help files that come with Visual C++ have a lot of the information you will need.

webmaster@lostlogic.com

I am going to be porting some pre-existing sockets code from Windows to Linux very soon. The pre-existing code uses WSAAsyncSelect() and messages to signal the application of various socket events. How does this relate to sockets on Linux where there is no message loop to speak of?


Steve 'Sly' Williams
Tools Developer
Krome Studios

Sly, polling with select() is the simplest method, but even that isn''t a 1-to-1 code change.

Julian, I''m a HUGE fan of C++ and portability is one of the primary reasons. Build a class library, with a hierarchy something like:

CNetMsg

CNetConnection
|
-CNetSocket
--CW32Socket
--CUnixSocket
|
-CNetDPlay
--CW32Dplay *not needed, since there is no DirectPlay for Unix, but it makes better sense in the hierarchy this way*

Use CNetConnection as an abstract base class that will declare the primary network interface, and then just override functions in all of the subclasses. You''ll be amazed at how simple this is once you get rolling.

Thanks for the idea. Yes, making a class to encompass the various methods looks good.

Looks like I''ll focus right now on Winsock. I''ve programmed DirectPlay before, but I''m itching to learn Winsock right now.

Yeah, class encapsulation is definately the way to go. Although Windows supports select() it is certainly not the most efficient method for socket operations under windows... unfortunately, the socket stuff is sufficient different between windows and unix that you really should write all the code specifically tailored to each platform.

Julian, you might also want to take a look at IO Completion Ports using Winsock 2 for high end server design on Windows. I''ve got a class library put together that can push a sustained 6.5 MegaBytes / second through a 100 Megabit Ethernet adapter on a dual P3-500. And that only uses around 30% of total CPU time.

Doing some rough math, figuring 4.5KB/s transfer for 56K users, the above setup could handle 1500 clients at a time (assuming that you had enough processing time for AI etc...)

I don''t have any desire to develop for unix, and I''m sure I''m not the only one. Win32 has made me fat and lazy, no need to change now. =)

The WinSock API was written with portability in mind (from what''s written in the msdn docs)

If you make your own classes, it should port with minimal problems.


I''ve never done this, but thats the way everything reads...


And 6.5MB/s is only 52% utilization of a 100Mbps pipe - which I guess is high for tcpip... but not the 95% you''d get with ipx