I recently started socket programming in Win32. I have programmed a server that can listen on an arbitrary port for a client to connect, and I can send info to the client which uses a blocking recv(). I've also programmed a client which connects to the server I programmed. And I've also created a client which connects to a Web server and does an HTTP GET request and receives data from the Web server via a blocking recv(). So I've got three things going here: a server, a client of the server, and a client of a Web server. After looking into WSAASyncSelect and a couple other possibilities (I even got WSAASyncSelect to work), I've decided to instead spawn a thread off for each client connection to a server, so a client can communicate with multiple servers. (And something similar for a server communicating to multiple clients). My question is this: which data objects need to be unique to each thread? For example, the server binds, listens, accepts, and then sends/recvs. Should I use one socket and start the new thread after accept, and only do the send function in the thread? As for the client, it's technique is to create the socket and then connect. If it wants to create a thread for each server it is talking to, should it create a separate socket unique in each thread and then within each thread do it's own connect and send/recv? [edited by - bishop_pass on April 24, 2002 2:26:47 PM]

So far, I think I''ve determined that on the client side we want this:

1) Start the thread
2) Create a socket (unique to this thread)
3) Set the ip (unique to this thread and this socket)
4) connect
5) receive using a buffer unique to this thread. recv will block, but it won''t block the application, because it is unique to this thread.
6) When done, close the socket, and return. The thread is over.

It''s the server that has me a little bit confused regarding how many sockets to use and which parts are unique to each thread communicating with a unique client.

Ok, I think I got it now for the server thread/s. Let''s assume we have an application that does other things besides being a server.

So, our application does this:

1) start a thread called server().
2) This thread is only started once, and runs concurrently with the main app.
3) The thread server() creates a socket, binds it, and listens on a port. It then enters a loop continually checking with the accept() function. The accept() function returns the client socket that is trying to communicate with the server. For each one of these new sockets returned by accept(), server starts a new thread: let''s call it server_client().

So, we start up multiple server_client() threads from within the server() thread, each with their own unique socket and buffer for communication.

Now, given that, how do we terminate the client_server() thread? Do we need to call shutdown or closesocket for the client socket, or does the thread just return?

Didnt go through all of your text but it is know that spawning one thread per client does not scale to a large number of clients :-( Look up something call IOCompletation Ports, I myself have not worked with them but I hear they will scale nicely. There are other ways around scaling but.. not sure if it is a concern.. just thought I would point it out before you get to far in :-)

cheers

At this point, I think threads are the way I want to go. I''m anticipating each client/server (let''s call it a peer) will be typically connected to somewhere between 1 and 10 other peers. Maybe, in a very extreme case, a peer might connect to as many as 100 other peers.

Anyway, this isn''t a MMORPG, it''s something different. So, if someone could clarify my questions (particularly the one about a server cleaning up when closing a client connection in a thread) that''d be great. The actual question I posed was in the last post I made in this thread.

OK, I assume that your server''s client threads are all blocked on a call to recv, waiting for stuff to come from the client. When they get something, they''ll process the data, send something back and block on recv again. Right?

There''s going to be two reason you''ll want to stop the server_client() thread. One is if the client disconnects, the other is if the server is shutting down.

If the client closes the connection, the call to recv which is waiting on that client will return with an error (you''ll have to look up the docs, I don''t remember specifically which error). In that case, all you have to do is return from the thread function (after freeing memory, etc).

On the other hand, if you want to shut the server down, but there''s all these blocked threads waiting on recv, then just call shutdown and they''ll all return with an error. I think it''s a different error, but it doesn''t matter because you do the same thing anyway: free your memory and return from the thread function.

---

codeka.com - Just click it.

Ok, thanks Dean. I might have enough to go on now to get the threaded server going.

quote:

---

Original post by Dean Harding
On the other hand, if you want to shut the server down, but there''s all these blocked threads waiting on recv, then just call shutdown and they''ll all return with an error. I think it''s a different error, but it doesn''t matter because you do the same thing anyway: free your memory and return from the thread function.

---

Ok, there''s one thing I''m vague on.

What if the client has not closed the connection with closesocket(), but the server wishes to close the connection between the server and the client? Now, the server itself doesn''t want to shutdown, but it does want to be done with this particular client and the thread it created to communicate to the client.

If the client_server() thread is between send() calls and decides that it is through with the client (for whatever reason), can it just call closesocket(clientsocket) and return from the thread? Is that all it needs to do? Will any potential data possibly in transit simply go away? Will the client get an error on its side and know that it no longer has a valid connection? If that is the case, does the client also need to close the socket with closesocket()?

The standard paradigm is where the client closes the socket, and then the server knows it is done. I''m just trying to see how to work it if the server decides to take the initiative and dump the client.

Yeah, the server would just call closesocket and then return. closesocket will block until all unsent/unacknowledged data is send/acknowledged. I just looked it up, and if the server closes the connection gracfully (which is what closesocket will do^*) the client''s call to recv will return 0, hence indicating it can free it''s own resources with a call to closesocket. Every call to socket should have a matching closesocket call to free the allocated resources.

^*To do an abortive close (i.e. don''t wait for unsent/unacknowledged data to be sent/acknowledged), you set the SD_LINGER option appropriately, you''ll have to look in MSDN for that, since it''s got a fairly long description...

---

codeka.com - Just click it.

Thanks for the info, Dean. So far, things are working.