New to network programming a couple questions:
 

So I'm making a MUD from scratch. At first it was going to be just a learning exercise but it's turning out to be a bigger task than I expected so now it's a full on project.

A couple questions about the network: is it a bad idea to make a new thread to handle each user's socket connection? I understand the main drawback with threads is their high memory use but if I specify a very small stack size (using _beginthread() on windows) wouldn't that handle that issue completely? Of course I'm coding with major success in mind so I'm planning to have my server support 1000 users at once (ridiculous I know, but better safe than sorry).

The upside for a thread for each user is that one guy with a slow connection won't slow down anyone but himself. Plus it actually seems alot simpler and more efficient than the thread pool I've implemented which has an ugly select() loop which I figure will eat up a lot of cycles.

I'm sure there is a pretty standard way to deal with connections in MUDs but I don't know lit.

Re: New to network programming a couple questions:
 

In short: Yes. The problem isn't with memory use, but with race-conditions - I suggest reading up on . What you're proposing has been suggested many times before, but there's a good reason why most people don't bother.

Re: New to network programming a couple questions:
 

I'm planning for the socket threads to dump their data into the main server thread which will handle it all. So the majority of the server's code would not be multithreaded, only sending data both ways would be multithreaded. Wouldn't that avoid the race-conditions problem?

Re: New to network programming a couple questions:
 

No, that's exactly the sort of place where the problem arises. When trying to push information from one thread to another it is far too easy to end up doing so in a completely unsafe way. It doesn't matter how 'much' is multithreaded - you have multiple threads, and they share data, therefore you're at risk.

1 thread per connection is both wasteful of resources and difficult to program safely with, which is why most people use different approaches.

Re: New to network programming a couple questions:
 

Crap. So I'd be best off just doing everything in one thread? With TCP wouldn't a few people with slow or bad connections slow everyone down? Is there anything special most MUD coders do to prevent this?

Re: New to network programming a couple questions:
 

No. The operating system will only tell you there is data once it's arrived, no matter how long it took to get there. You just have to copy it over, which takes the same amount of time whether they're on your local LAN or a 1200bps modem from 1983.

Most muds use the select() function to be told which sockets have data waiting, and have a local buffer for each socket. When the data is ready on a socket, read it and add it to the end of the buffer. If the buffer contains enough data to read a command out of it, read it and process it, taking the data out of the buffer. Repeat for as many commands as you can read, and for as many sockets have got new data.

Re: New to network programming a couple questions:
 

You could look into threading for any processes that don't need to feed back into the main loop at all or do so infrequently. Any task that can be delegated fully and whose outcome doesn't have to be 'synced up' at all is a very good candidate for threading. For instance, saving the player stats / config to a database / file. If you implement that, then in theory you can save stats / configs more often and for more players without slowing the main game thread.

Loading stuff up into the memory can also be threaded but it can be considerably trickier. I imagine you'd have to set some kind of a wait state on the socket that requested something to be loaded from db/disk and only service it when the data is ready. You'd have to remember what unique data this particular socket is waiting to receive from the loading thread. A good example is when a player first enters the game.

I haven't done either threaded saving or loading myself but I'd start with saving. In weighing the pros and cons to either, keep in mind that spinning off and managing threads is itself costly. If you have to do it too often, it may defeat its purpose and actually worsen overall performance.

Perhaps someone with practical experience in threading will pitch in with more/better advice.

Re: New to network programming a couple questions:
 

Saving data could also cause problems - what if the main thread tries to loads the data while it's being saved? You'd need to use a mutex for both saving and loading the pfile.

A more common use of threading is for DNS lookups. I also do a WHOIS on the IP address at the same time.

Re: New to network programming a couple questions:
 

Thanks guys. I decided to go with a simple single threaded approach for now. You guys would probably laugh if you saw the ridiculous thread pool system I coded before asking this question. I don't know why I though it would maximize performance. I'll be sure not to be so reckless with threads in the future.