Writing A Server

I've been messing around with socket programming lately, and I've realized that there are two possible ways to write a server.
One, with Java, you can say something like

Code:

---

SocketServer server = new SocketServer (port);
Socket client;

while (true)
{
    client = server.accept ();

    if (client != null)
        // do something
}

---

However, I've been using wxWidgets, and I looked at their socket libraries, and they differently. The program doesn't have to sit in a loop and wait for connections. Rather, whenever the server gets any activity on the port it calls a function that you define.

Code:

---

void classname::OnSocketEvent (wxSocketEvent &event)
{
    // do something
}

---

This, in my mind, is just like interrupt programming.

Which of these two ways is best? Which should I use? What are the advantages and disadvantages?

The second method is called asychronous socket programming, while the first method is traditional blocking sockets.

Quote:

---

Which of these two ways is best?

---

Neither way is best, just use whichever method works best for your particular program. In my experience, asychronous sockets are easier to use for client applications, and blocking sockets are easier to use for server applications.

Since your post is asking about server side programming, I will talk a little bit about the pros/cons regarding server sockets.

The way I usually do a server is with blocking sockets, where a new thread is spawned for each new connection. This has the advantage where each thread can handle it's own connection, and you dont have to worry about sending the wrong data to the wrong client. It is also very easy to keep track of all the connected clients this way since each thread represents a client. One thing you need to be aware of here though, is that any shared data (data that is accessed by different threads) needs to be thread safe to avoid data corruption.

With asychronous sockets on a server, everything runs on a single thread. This is always nice because you never have to worry about corrupting data via threads. The downside here though is that it is easy to lock up the server and have client waiting long amounts of time.

Imagine the following function gets called when data is available to be read from the socket:

Code:

---

CMySocket::OnReceive()
{
  // While you are processing the data here, all other socket connections are on hold.  If
  // the server takes 1 second to do the processing for a connection, and there are 50
  // clients connected, you are in trouble. 
}

---

A threaded server on the other hand can simply context switch to another thread at any time.

OK, that clears things up pretty well. I was just kind of afraid that I was doing something wrong.

Couldn't you still spawn new threads with traditional blocking? I mean you could say

Code:

---

while (true)
{
    client = server.accept ();

    if (client != null)
        // create new thread
}

---

Quote:

---

Couldn't you still spawn new threads with traditional blocking?

---

Yes, in fact you dont really have a choice here. If you are using blocking sockets you have to spawn a new thread for each new connected client.

>>If you are using blocking sockets you have to spawn a new thread for each new connected client.
No, you don't. I've managed to squeak by for some time using select() with a timeout of 0, to check whether any clients have events waiting... although that's almost certainly not an ideal solution, it works and doesn't have thread data-corruption problems, and you don't get the excessive context switches that occur when you have too many threads (or so I've heard). But if you do this, you can probably just go with asynchronous sockets since in essence that's what you're doing - although this way you do have the option of blocking.