Hi, i'm starting to create a 3D chat and i'm implementing a simple server to send e recive message from all client connected. I need to know more information about all clients connected for example the "ID" or "nickname". So i need to know which is the better to create a Server for this chat. Multithreading or WSAAsyncSelect? This application will run on windows system only. Thanks a lot, and sorry for my bad english.

Asynchronous sockets with a fixed pool of threads proves to be faster than a thread per synchronous socket.
On windows, however, you should consider IO completion ports as the solution for asynchronous I/O.

Quote:Original post by loufoque
Asynchronous sockets with a fixed pool of threads proves to be faster than a thread per synchronous socket.
On windows, however, you should consider IO completion ports as the solution for asynchronous I/O.

For a chat application that's complete overkill. Async sockets will be fine if you're not expecting a lot of bandwidth.

WSAAsyncSelect will stuck you with 65 connections per thread. I think you are not just doing a chat server, you are doing so with a grater purpose(learning), so, you really must check out completion ports.

Ok thanks a lot. I will try soon.

Quote:Original post by Escarab
WSAAsyncSelect will stuck you with 65 connections per thread. I think you are not just doing a chat server, you are doing so with a grater purpose(learning), so, you really must check out completion ports.

Really? Where does it say that? It's my understanding that the 64 socket limit only applies to WSAWaitForMultipleEvents.

Also, as a learning exercise, IOCP is going to be a nightmare. You really need a good grasp of multithreading and sockets before considering IOCP.

TCP or UDP?

Quote:
Original post by Evil Steve
Really? Where does it say that? It's my understanding that the 64 socket limit only applies to WSAWaitForMultipleEvents.

Ops, my bad, you are right, I don't know what I was thinking that time.

I've suggested IOCP, because I'm pretty sure he is not doing a chat server because he wanna do a chat server, but because he is trying to learn something useful for a larger server in the future (mmo?).

IOCP is the way to go if you are trying to do a server that handles many connections(TCP). So, I think he is better skipping WSAEventSelect, WSAAsyncSelect...
At least, it's how I did it. IOCP is not that difficult, it's just a myth to scare people away, once you get the concept, it's pretty easy.

p.s: I am considering that he is able to use blocking sockets already, start from scratch with IOCP is not a great idea.

WSAAsyncSelect has really nothing to do with the network at all except it requests a message to be delivered to HWND upon a network event has happened. It is completely unusable in a server that is a console application and has no any window API objects :)

IOCP could be the answer.

And IOCP itself differs through Windows versions. With Vista and Server 2008 you can use a more advanced GetQueuedCompletionStatusEx() that functions in bulk mode by receiving many events per one system call that is more appropriate for the highload server (similar to epoll, kqueue). With earlier versions like XP, 2000 and Server 2003 there is the only possibility to use older GetQueuedCompletionStatus() what only fetches one event per one call and has a bit different logic that leads to more confusing braching in processing of what it returns.

P.S. Using threads is also an option. IOCP is more sutable for servers that must support high number of simulateneous connections (1-2k and more). However I've seen a source code of servers (where clients must interact with each other) that was written by developers not knowing about IOCP and similar techniques - what they did looks like a simulation of asyncronous techniques using threads (like a lot of communication threads only generate events for a single event processing thread that in its turn offloads I/O operations to communication threads) :)

Quote:Original post by Advanced Customer
WSAAsyncSelect has really nothing to do with the network at all except it requests a message to be delivered to HWND upon a network event has happened. It is completely unusable in a server that is a console application and has no any window API objects :)

I wouldn't say that it is totally unusable; you just have to make your code create a hidden window and implement the WndProc for that window. To use Win32 in a console, all you have to do is include windows.h and you have access to the Windows API objects ;) In fact, I don't recall seeing many servers that run a Win32 gui rather than a console.

- (What follows is an argument in TCP perspective)

I think that if you are going asynchronous sockets via a Win32 HWND, you should design your code to run in its own thread and have it's own dedicated HWND for processing network events. I would never suggest to someone to couple network code and GUI code in the same WndProc, even if the design of WSAAsyncSelect allows you to do so. There are many reasons for this but, if the GUI stalls, the network then stalls, so separate threads is more reasonable.

What I did in my network code was make it so the client/server that uses WSAAsyncSelect has its own dedicated HWND and shares a common network WndProc (remember that you can use SetWindowLong with the GWL_USER option to set a pointer for that Window and have one WndProc function definition that can service all of your objects).

What results is a nice network library that I can use alongside any Win32 project without worrying about the type of Win32 app it is or what framework/libraries it is using. Overall, I am very happy with it [smile]

The immediate downside to the design is that, since it is a single thread handling the network data for many connections, it won't scale well towards the 500 connection or so mark if you have a lot of traffic and data processing done in that same thread. Instead, you'd have to come up with a more appropriate solution that would allow the network code to handle the network data and have that thread post data to another thread that actually does the processing to prevent such a bottleneck.

But, that is the natural limitation of such a design, if you need a moderate number of connection, the strategy works fine. If you want several thousands on Windows, you choose the better strategy, IOCP. However, the complexity of getting different network strategies down is a key factor in deciding what to use.

TCP is not an easy protocol to design around if it is your "first attempt". I've been playing with it since early 08 and I still find bugs in my code [lol] My code now is a lot better than it was before, but understanding what you really need to account for when you design your code around TCP is trial and error as well as a long learning process you just build up with experience.