Archived

This topic is now archived and is closed to further replies.

cronong

has anyone actually used Dplay and think it's bad.

Recommended Posts

cronong    122
so, many people have claimed that Dplay has a ceiling of 20-30 players, but then they all said they haven''t personally tried it but it''s what they heard. i''m realyl interested in seeing if anyone has actually experienced Dplay and found out that it really really sucked? like hitting a top of < 200 players or so. if so, was that old Dplay or Dplay8.1 / 9 (same thing i guess).. coz MS claimed "Dplay 8.1 is designed with MMOG in mind..." Thanks

Share this post


Link to post
Share on other sites
KalvinB    102
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.

Share this post


Link to post
Share on other sites
foofightr    130
Kalvin, telling it to allow 1200 connections and actually having 1200 active clients are two very different things. I can tell my Winsock-based server to "allow" 4.2 billion clients...

What is the most active clients you ever had using DPlay? I've read about (and repeated to others) the 20-30 client limit, but it would be nice to know about hard facts, not just what I've read...

[edited by - foofightr on July 9, 2003 1:37:40 AM]

Share this post


Link to post
Share on other sites
KalvinB    102
"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]

Share this post


Link to post
Share on other sites
RonHiler    214
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

Share this post


Link to post
Share on other sites
KalvinB    102
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.

Share this post


Link to post
Share on other sites
RonHiler    214
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

Share this post


Link to post
Share on other sites
Sikara    122
My armchair opinion (yes, I know everyone is interested), is that the performance degradation wouldn''t be noticeable.
The main problem with directplay is that the protocol is proprietary, so you really don''t know whats going on under the hood.

I agree with KalvinB, I think directplay would work fine for a MMOG. The issue is whether you want to use a windows server or not.

Share this post


Link to post
Share on other sites
cbenoi1    484
> Which means DPlay is constantly monitoring all these statistics. {...}
> This has to cause the packets to be bigger

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.

> Nobody seems to have any hard numbers about what DPlay
> can do, at least any recent ones.

There are some benchmarks on DP7 and below, but DP9 is an entirely new beast; my take is that the performance has gone _way_ upstairs.

> {...} experienced Dplay and found out that it really really sucked?

NAT support is still a big hack, even with the new NAT support. Still, only a few NAT configurations can be bypassed. Setting up a threaded infinite enumeration is a joke.

> 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 expect DP to be slower than straight Winsock; however, I do expect MS to fiddle with the API in the forthcoming versions both on the performance and usability sides. DX3''s immediate rendering pipeline was a laughing stock, and then DrawPrimitive() came along. DP3 was the API from hell, but then DP8 got the P2P and C/S topologies and messages straightend up. Don''t discount MS''s ability to upgrade an API as important to its business as DirectX.

-cb

Share this post


Link to post
Share on other sites
RonHiler    214
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.

Share this post


Link to post
Share on other sites
cbenoi1    484
> I think RoundTripLatencyMS, ThroughPutBPS, PeakThroughPutBPS, and BandwidthBPS
> would require extra packet information to be transmitted.

Packets marked as ''garanteed'' delivery will play a determinant role in updating this value, I imagine. Garanteed packets are numbered, if this is what you are referring to as ''extra information''; honestly, I don''t know how you would implement some form of reliable UDP protocol that garantees packet delivery without at least an embedded packer number. Besides, anything that relates to BPS and MS is stated in the docs with the comment: "This value is approximate, and you may want to calculate your own value for greater accuracy." If there were no garanteed delivery packets exchanged within some recent timeframe when the call to ''GetConnectionInfo()'' is made, then I suspect DP9 will send such a packet to have some meaningful measurements (hey, you asked for timing result, right?).


-cb

Share this post


Link to post
Share on other sites
zfod    122
Heh,

I don't use Dplay because it is proprietary, has questionable feature creep that I honestly don't need in a low-level library and because I don't use Windows as a server platform.

Also, how many more retards will make games that aren't compatible with {N|P}AT? Dplay doesn't help in this area. Why must people use original IP header information and stuff it into the payload to use higher up in the stack in processes that effect connectivity ( hell, or anything really )? This is simply amazing to me, in the year 2003 with IPv4 still predominately in use.

Is Dplay capable? Sure. Does it meet my needs? No, and it probably never will.. version 10 or 100 unless the fundamental proprietary aspect changes ( or the nature of my work changes completely ).

I think if you have some very specifically supported needs, you don't need to know much of anything ( or touch anything under the hood ) related to the aforementioned specifics, or you're not relying on a ton of flexibility ( forseen on any level ) in your network code..... then Dplay is great for you providing you're homogenous across the board.


.zfod


*EDIT* Re-wording

[edited by - zfod on July 9, 2003 8:12:46 PM]

[edited by - zfod on July 9, 2003 8:13:54 PM]

Share this post


Link to post
Share on other sites
Anon Mike    1098
I have used DPlay in applications with upwards of a couple thousand simaltaneous connections. It can be made to work but you have to play by it''s (unwritten) rules or you will get regret it.

The first is that DPlay must have plenty of cpu. If you don''t give it enough cpu time it will start dropping connections (which increases it''s workload which leads to more dropped connections which increases it''s load further). If you don''t use the thread pool feature you *must* put Sleep''s in your loops to unsure that DPlay threads get enough cpu. Relying on the OS thread schedule is not enough, DPlay demands more.

Practically speaking you pretty much have to use the thread pool feature if you want to scale this high.

DPlay will throttle it''s bandwidth to a given user. This is fine but under load it will throttle it to the point that its pings get through but no data does. This means that you have a "live" connection but it has no useful activity. Meanwhile DPlay keeps allocating resources for all this backed up data until your server falls over.

I eventually gave up fighting and switched to a staight winsock based network layer. It took me about a week to do and stabilty and resource usage improved dramatically.


Share this post


Link to post
Share on other sites
RonHiler    214
Ah, thanks Mike. That''s the sort of info I was hoping someone would post. So the bottom line is that DPlay would probably be okay for a small MMOG (<1000 connections?).

Good to know. -Ron

Share this post


Link to post
Share on other sites
zfod    122
lol,

I don''t know Ron, but I read what Mike was saying as a clear indication that you would NOT want to use Dplay.

Just because you can get something to behave in a certain fashion doesn''t mean that it is optimal or intelligent, which is what I gleaned from his post.

I''m not trying to sway anyone in any certain direction, just trying to point out what I see ( my own experience and from what has been said from others'' ).


.zfod

Share this post


Link to post
Share on other sites
KalvinB    102
DPlay should at the least be seen as a crutch that gets people who aren''t skilled with coding networking in the door to code on-line games.

It just works. Which is why I liked it a lot when I first used it. There were no surprises when I went from LAN to the net with my DPlay project. Now that I understand networking enough I was able to get the same lack of surprises with Winsock and TCP/IP.

Ben


IcarusIndie.com


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

Jessika - Sure I can accept all forms of payment.

Share this post


Link to post
Share on other sites
cbenoi1    484
> I have used DPlay in applications with upwards of a couple thousand simaltaneous connections.

Thanks a lot, Mike. Very useful information.

> I eventually gave up fighting and switched to a staight winsock based network layer.

Do everyone, yourself and MS a favor and bitch your case by email at ''directx@microsoft.com''. Last time I did have problems with a MS API and bitched loud enough, I got an excuse email back from the Program Manager himself and a free MSDN/Ent subscription.

-cb

Share this post


Link to post
Share on other sites
RonHiler    214
quote:
Original post by zfod
I don''t know Ron, but I read what Mike was saying as a clear indication that you would NOT want to use Dplay.


I guess it''s all in how you read it, hehe. It depends, I suppose, on when DPlay started to become problimatic. He said he was running ~2000 connections and having problems. So I just cut his number in half and figured it''d probably run fine at that level Mike, any input on at what point you started to see instability?

I think we can safely say that the 30 person limit is no longer true

Share this post


Link to post
Share on other sites
Anon Mike    1098
It''s not a number of connections thing, it''s what your workload is.

I have seen DPlay work fine, with no special care in how it was used, with 5000 simaltaneous connections to a single server. However there was very light traffic on the connections so the cpu utilization never got above 50%. Also this was on a 100Mb LAN so bandwidth and round-trip-time was at it''s best.

Under heavy load I''ve seen it fall over with as few as 100 connections. This is over the Internet with lots of traffic on each connection. By fall over I mean the cascade failure I mentioned above where DPlay starts dropping connections which causes it to increase it''s own workload for a time which causes it to drop more connections, etc.

IMHO DPlay works fine in situations where it was seemingly originally designed for - small LAN-based games. It can be made to work for other situations but it requires a good bit more babying. If you want a rule of thumb I''d say you need to be willing to commit 50% of your cpu on the server and probably 10%, at a minimum, on the clients to ensure good performance.

If you are already familiar with socket programming and have at least some grasp of what completion ports are then I see no advantage in using DPlay over winsock.

Share this post


Link to post
Share on other sites