DPlay has no hard coded limits. People that tell you otherwise are either misinformed or lying.

DPlay 7 had no problem with me telling it to allow 1200 connections. However, it would definitly take Win2K or better to make that many. Windows 98 doesn''t handle lots of simultanious connections as well as NT which was built for such things.

The reason I made the switch to Winsock was because DPlay

a) makes the product not portable
b) doesn''t fit into a plug and play class very nicely

I recommend DPlay to people who don''t want to learn the nitty gritty of networking for real time games and don''t care about portability. DPlay is very capable.

Ben


IcarusIndie.com


KalvinB - (to Jessika) do you accept Jesus as your lord and savior

Jessika - Sure I can accept all forms of payment.

"What is the most active clients you ever had using DPlay?"

Not more than a couple as I never released a major DPlay based game. But DPlay, like Winsock, is limited by the OS. I've established a couple thousand connections between two Win2K machines with Winsock TCP/IP. Because DPlay isn't very class friendly it's far more difficult to do such a stress test with it.

from

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnplay/html/dp8ovrview.asp

"This [peer to peer] topology is most suited to smaller multiplayer games typically reaching a maximum of 64 players at any given time. It is important to note that DirectPlay 8 does not impose any restriction on the number of connections used in any topology. It is up to the game developers to monitor resource usage and determine the performance level appropriate for their particular game."

The same can be said for Winsock. Peer to Peer is a resource whore for either API.

also

"The use of NT I/O completion ports allows DirectPlay to increase its efficiency by using a limited number of threads to service I/O operations."

IOCP is what's used with Winsock to achieve massive amounts of connections. Unless you're an experienced programmer, you're not going to able to do IOCP with Winsock with the speed that DPlay has implemented it.

Ben


IcarusIndie.com


KalvinB - (to Jessika) do you accept Jesus as your lord and savior

Jessika - Sure I can accept all forms of payment.


[edited by - KalvinB on July 9, 2003 2:10:46 AM]

quote:Original post by KalvinB
Not more than a couple as I never released a major DPlay based game.

Then you''re in the same boat as the rest of us, heh. Nobody seems to have any hard numbers about what DPlay can do, at least any recent ones. Up until a couple of days ago, I believed the 20-30 person limit, but I''m beginning to suspect this is from old versions of the API. Sure would be nice if someone would step up and say, "Yes, I limited DPlay 9 at X number of active connections, after which it started to bog".

quote:
Because DPlay isn''t very class friendly it''s far more difficult to do such a stress test with it.

I don''t understand why you keep saying that. I had DPlay encapsulated in a class just fine. Which part of it do you consider class unfriendlly?

quote:
"The use of NT I/O completion ports allows DirectPlay to increase its efficiency by using a limited number of threads to service I/O operations."

Somebody mentioned this in another thread, and it was a big surprise to me. This is why I think the 20-30 person limit is old data. IOCP should allow for a lot more than that.

quote:
Unless you''re an experienced programmer, you''re not going to able to do IOCP with Winsock with the speed that DPlay has implemented it.

Totally disagree with this statement. Have you seen the sort of statistics DPlay keeps track of for you? It''s a nice API (it really is, I *liked* it when I used it to prototype my current project), but as usual Microsoft has bloated it with a bunch of stuff that is bound to slow it down versus a straight Winsock API. I don''t think DPlay IOCP will come anywhere near approaching the level of a Winsock IOCP server. Again, I''d love to get some hard data on this

Ron

The 20-30 limit is old FUD. I''ve never found anything to indicate there is such a limit.

"I don''t think DPlay IOCP will come anywhere near approaching the level of a Winsock IOCP server."

think==FUD

And only then if you''re an experienced programmer. For many people there''s no point in trying to use Winsock to do guarenteed UDP because they''ll just reinvent a slower version of TCP/IP. Likewise, most people who do IOCP with Winsock are just going to reinvent a crap version of DPlay.

Every argument I''ve seen against DPlay is just assumptions ("It''s MS so it''s crap" and other such garbage). And commerical games DO use DPlay on occasion. The problem with MMOs and DPlay is the cost. It''s a lot cheaper to use sockets and a free OS on all the servers than DPlay and Windows. Sockets also give programmers more control as you have access to a lower level than with DPlay.

Ben


IcarusIndie.com


KalvinB - (to Jessika) do you accept Jesus as your lord and savior

Jessika - Sure I can accept all forms of payment.

quote:Original post by KalvinB
The 20-30 limit is old FUD. I''ve never found anything to indicate there is such a limit.

Perhaps not anymore. There *was* once such a limit, and I think perhaps the perception of that limit has carried through to current versions, even if it''s not deserved. That''s what I''d like to know, what''s the *current* limit?

quote:
Every argument I''ve seen against DPlay is just assumptions ("It''s MS so it''s crap" and other such garbage).

Yeah, but that argument doesn''t work with me. I''m not anit-MS. On the contrary, I think DX is the best invention for programmers since sliced bread. Don''t get me wrong, I do like DPlay quite a lot, it was very easy to use. Much easier than an coding an IOCP server, heh.

I just have a hard time believing that DPlay can possibly be as efficient as Winsock. Do I have any hard data for this? No. I only have what seems to make sense. Just as a for instance, if I call the DirectPlay8Client->GetConnectionInfo() routine, I get back a structure that gives me all this stuff:
RoundTripLatencyMS
ThroughPutBPS
PeakThroughPutBPS
BytesSentGuaranteed
PacketsSentGuaranteed
BytesSentNonGuaranteed
PacketsSentNonGuaranteed
BytesRetried
PacketsRetried
BytesDropped
PacketsDropped
BandwidthBPS
MessagesTransmittedHighPriority
MessagesTimedOutHighPriority
MessagesTransmittedNormalPriority
MessagesTimedOutNormalPriority
MessagesTransmittedLowPriority
MessagesTimedOutLowPriority
BytesReceivedGuaranteed
PacketsReceivedGuaranteed
BytesReceivedNonGuaranteed
PacketsReceivedNonGuaranteed
MessagesReceived

Which means DPlay is constantly monitoring all these statistics. I''d have a very hard time believing all this comes for free. This has to cause the packets to be bigger and the speed of dealing with packets to slow down to some degree. And this is only one example, there are several of the same sorts of things scattered in DPlay which make me think it can''t possibly work as efficiently as Winsock.

That''s where I''m coming from. I could be wrong, perhaps MS found some way to get us all this sort of data without causing things to slow down, I don''t know. I''d be happy to be proved wrong

quote:
I don''t see anything in your list that would require extra packet information or something else other than passive counters in the DP object.

For the most part that''s true, but unless they have some way of calculating it that I don''t understand, I think RoundTripLatencyMS, ThroughPutBPS, PeakThroughPutBPS, and BandwidthBPS would require extra packet information to be transmitted.

quote:
however, I do expect MS to fiddle with the API in the forthcoming versions both on the performance and usability sides

Absolutely. They have a clear history of doing this. It takes ''em a couple of tries, but they do get it right after a while Is DPlay 9 the point at which DPlay becomes usable for a MMOG? Maybe, I dunno. Even if it''s not, by 10 it probably will be.