I have read quite a handful of topics in this board, but I still do have questions. My task is a online game with the following specifics: 1) Turn-based. No massive amount of data (see below). 1) 10K+ clients playing 2000+ card games. 2) Insignificant amount of data transferred: Server->Client < 40-byte request once a second. Client->Server < 1-byte request once in 5-10 seconds. 3) Authentication/Encryption required. Now the questions... I. Unix, Windows and APIs 1) Unix or Windows? 2) If it is Windows, I am bound to IOCP, am I? I have heard that IOCP is not for Win95 users, is it? What are the client OS requirements when using IOCP? Can I include IOCP in my client software setup if support for old systems? What about DPlay? Will it provide the performance and can I install it on client machines? 3) If it is UNIX: is there a mechanism on UNIX that will provide the performance required? II. The protocol 1) I understand that TCP sucks in my case. Does it really? I feel no compassion for encrypting myself.

Unix or Windows?
Whichever you feel more comfortable with.

If it is Windows, I am bound to IOCP, am I? I have heard that IOCP is not for Win95 users, is it?
You do not have to use IOCP on windows, but it will provide the best performance. IOCP should only be used on the server side anyway, not on the client side, so operating system requirements should not be a concern.

What are the client OS requirements when using IOCP? Can I include IOCP in my client software setup if support for old systems?
See above.

What about DPlay? Will it provide the performance and can I install it on client machines?
I know very little about DPlay myself, so I can't offer much advice on this. But personally, I would suggest that you don't use it. As far as I know, it is designed more for fast paced games like FPSs, where you need a constant stream of data, but there are relatively few clients connected to each server.

I understand that TCP sucks in my case. Does it really? I feel no compassion for encrypting myself.
TCP does not suck in your case. It would probably be the correct choice. However, it has no built in encryption capability. That must come at a higher level (this is true of any low level protocol though - none of them provide built in encryption). What TCP does provide is a reliable, stream based protocol. Meaning that data you send will all be received in the correct order. For a slow game like the one you are describing, this is fine. If you were to use the other main low level protocol - UDP - then you would almost certainly end up writing your own reliable, sequenced protocol on top of it, which would be a waste of your time.

John B

[edited by - JohnBSmall on October 21, 2003 6:39:07 AM]

Thank you, John.

Whichever you feel more comfortable with.
Does that mean that both have equally potent and usable means?

You do not have to use IOCP on windows, but it will provide the best performance.
That is what I meant

IOCP should only be used on the server side anyway, not on the client side, so operating system requirements should not be a concern.
This is a relief. I started to believe that it is something like DirectPlay - AFAIK, it requires DirectPlay on client. Though that leaves me with more options. "Decisions, decisions..." (c)

I know very little about DPlay myself, so I can''t offer much advice on this. But personally, I would suggest that you don''t use it. As far as I know, it is designed more for fast paced games like FPSs, where you need a constant stream of data, but there are relatively few clients connected to each server.
This is pretty well an advice That kills one of the options.

TCP does not suck in your case. It would probably be the correct choice.
Can I say that that UDP is for fast-paced game where data exchange occurs frequently?

However, it has no built in encryption capability.
I meant SSL. Though probably this will not be my choice due to performance reason. Unless someone tells my that I can SSL very quickly.

What TCP does provide is a reliable, stream based protocol. Meaning that data you send will all be received in the correct order. For a slow game like the one you are describing, this is fine.
That certainly makes sense - I believe one chooses UDP when he needs to send very frequently. Is that right?

If you were to use the other main low level protocol - UDP - then you would almost certainly end up writing your own reliable, sequenced protocol on top of it, which would be a waste of your time.
That is the way many people follow, isn''t it? Custom guaranteed delivery over IOCP + UDP - is that not the way lots of projects use?

Thank you once again.

Eugene Lisitsin

quote:

---

That is the way many people follow, isn''t it? Custom guaranteed delivery over IOCP + UDP - is that not the way lots of projects use?

---

In this case, no, you do not need to use UDP. However, good luck finding a way of efficiently maintain all of those TCP connections (e.g. you are pretty much stuck with IOCP on Windows).

If you use UDP you won''t need IOCP. But UDP is only necessary if you have real-time data requirements, or huge numbers of connections that need timely service (or like most MMOs, both). TCP offers neither (with or without IOCP).

Good luck with your game.

fingh

In this case, no, you do not need to use UDP. However, good luck finding a way of efficiently maintain all of those TCP connections (e.g. you are pretty much stuck with IOCP on Windows).
Well, it seems its IOCP on Windows and Async IO on UNIX. AIO Solaris lib, for exapmle.

If you use UDP you won't need IOCP. But UDP is only necessary if you have real-time data requirements, or huge numbers of connections that need timely service (or like most MMOs, both). TCP offers neither (with or without IOCP).
Is 10000 a huge amount? Customer requirement. No problem buying flashy hardware, but that doesn't mean I can develop mindlessly.

Good luck with your game.
Thanks

Eugene

[edited by - lisitsin on October 22, 2003 12:09:57 PM]