I am working on my text-based MMORGP, but I have encountered a problem with TCP Programming. Should I keep the connection active and just spawn new winsock controls for each client using port assigning and distribution? (I tried this before, but reached a limit of about 100 connections) Or should I just connect and then disconnect after sending and required information? (I'm worried that I won't be able to send important information to the client when needed...) Maybe there's a method I'm missing? Thank you all for your help, --Garrett P.S. I'm using Visual Basic, just in case anyone is wondering.

You really should keep the TCP connection alive for each client; that's much less resource demanding than spawning a new connection for each transaction.

But what happens when I have over 100 connections and VB won't let me make any more WinSock controls? (I used dynamic control creation before...) You can only have 1 computer connected to a port, right?

I really don't know about VB, but in C++ there's a few ways of handlng connections. A Win 2k/XP machine should be able to have about 4000 connections before you start getting errors (After about 4000 connections I got errors from Winsock about running out of buffer space).

You should definitely keep the connection open, since if the connection is closed, and you need to contact the client, you're screwed [smile] You'd have to contact them, which will cause issues if they have a firewall or are behind a router or gateway.

If you don't want to keep the connections, you might as well use UDP instead of TCP. Reestablishing connections with TCP just introduces a hell of a lot of overhead.

Practically all MMOs use what you could call a "connection multiplexer". These are seperate processes that pretty much all they do is take a few client connections and forwards packets to another process.

Here's a simplified diagram of an MMO architecture:

+-----------------+|  user server    |-----++-----------------+     |                        |                        |+-----------------+     |    +----------------------+   +--------------+|  user server    |-----+====| user central process |---| game process |+-----------------+     |    +----------------------+   +--------------+                        |                        |+-----------------+     ||  user server    |-----++-----------------+

These processes can run on the same or different physical machines depending on resource availability. Usually you should be able to get a few hundred players per user server; maybe less if you have a bandwidth hungry game like WoW, but in general you should be limited to what the operating system will give you in terms of sockets.

Basically what happens is that clients connect to the user servers which all connect to a UCP. The UCP then would be connected to multple game processes and the packets are usually then sent to the game processes.

At least that's the way it's worked on all of the MMOs that I've worked on (UO, TSO, some others you've heard of...). I know it works like the for WoW and DAoC too. Not sure how else you'd do it.

But to answer your question, you should keep the connection alive.

UDP would allow you to manage your connections as you see fit. Basically, you can use sendto() and recvfrom(), and you can keep sockets under a reasonable number.

The hickup is, you have to do all the work yourself (manage connections with each clients yourself, reliable messages and message buffering, message ordering, ect...). That might be a lot of work though, but you'll be limited, not by your winsock libraries, but by your own limitations (heap size, mostly).

THis is what I am actually trying to implement, but it's for arcade games, with almost constant data streams, so I can manage states myself (delta compression, no worries about out-of-sequence messages or duplications, ...).

but closing / opening sockets for each message really is asking for trouble. Plus, you do need to keep track of who is connected for security reasons and player management.