If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

To replace CAsyncSockets with WinSock, THAT's the question...

Hi,
I've large project (FTP Server) which is based on CAsyncSockets. Unfortunately, sometimes while high utilization, it doesn't manage it (eg. it hangs up in CAsyncSocket::Receive()).

And here comes the question: I'm interested in the fact, whether it would help to replace MFC Sockets with WinSock sockets (I mean WSAXxx() functions). Would the result be worth the effort to replace it?

You see, it's not easy to force myself to do such a big change in this project, which is otherwise completed.

Actually it won't be such a big change. You can implement your own version of CAsyncSocket with the same interface (i.e. same member functions & overrides) using Winsock. Then you'll have total control over how it works.

I'd have a class CAsyncSocket2 which is derived from CWnd, which on connection calls ::connect etc and creates a hidden window for itself. Then use ::WSAAsyncSelect to process messages and pass them to your own OnReceive/OnClose etc virtual functions.

Not too difficult I would say.

I might add I've already done this, only my stuff fires up a seperate thread to handle incoming messages using WSAEventSelect (the reason for this is because the threads are part of a pool to do receives so one machine can cope with thousands of concurrent connections without having to have thousands of windows). I also have seperate threads to do the send too just in case of blocks/can't send because receiving messages (again part of a thread pool).

Anyway for your case just using windows should be fine if you're wanting <50 connections per server.

So in conclusion, just implement all the same functions as in CAsyncSocket (i.e. Create, Send, OnReceive, OnClose etc) in your own class but use winsock instead.

Using CAsyncSelect and CWnd to process your messages you should be fine up to around 300 connections (I said 50 connections in haste). But you must bear in mind if it's single threaded it will suffer from a linear degredation of speed with every connection.

I had a similar situation on a 2.4GHz machine (nothing special) with 256Mb RAM and ran 300 connections without any problems on it apart from slowdown (obviously). It wasn't too bad though.
Pretty good all things considered, but every operation was pretty quick (i.e. I'd open files, and then just read from them and post the data in chunks of 64k).

But I needed to be able to cope with thousands of connections which is why I used multi threading to speed it all up.

Originally posted by darwen
I'd have a class CAsyncSocket2 which is derived from CWnd, which on connection calls ::connect etc and creates a hidden window for itself. Then use ::WSAAsyncSelect to process messages and pass them to your own OnReceive/OnClose etc virtual functions.

Creating hidden notification window is just something I would like to get rid of - that's the way MFC Sockets work. But I hope WinSock uses some more intelligent way, doesn't it?

Maybe I didn't emphasize it adequately, but I also want to know, whether problems I currently have (eg. being frozen up in CAsyncSocket::Receive()) COULD be solved with using WinSock instead...

But my problem is that CAsynSocket::Connect always return WSAEWOULDBLOCK even server exists or do not.

So my solution is that I derived CAsyncSocket::Connect where I call Connect twice continuously. The last return value will be the desired value. It works well in WinXP. In Win2000, or Win98, some time my Connect() implementation raise error.

Oh, and why do you need to check the status of the socket ? If you haven't received a close notification then the socket is live. This works in 99.99% of cases : the only times I've found when close sockets aren't send is either when you pull the power lead out from the back of the machine or when there's been a catastrophic OS shutdown.

Even in these cases, when you call 'send' afterwards it flushes a close message through anyway.

You could of course just do a send of a small amount of data that your server will ignore. This'll check the connection for you.

MSDN says: WSAWOULDBLOCK is return that means that CAsyncSocket is doing something, and if connect successfully, OnConnect(UINT errorCode) will be called. This is , I think, why this class is called "asynchonous" (CSocket always return the desired value). But if fact, it work differently, errorCode is the same return value of CAsyncSocket::Connect(...). So this way to check connection status is impossible. If there is any hidden thing, please let me know.

Another way, I can check easily connection status at connect(...) statement. By sending handshaking data to server, if no reply, connection could not be established. Handshaking protocol is server-specific, and it can not be generalized. This is similar to your idea:

You could of course just do a send of a small amount of data that your server will ignore. This'll check the connection for you

Another solution, I think that we should reimplement CAsyncSocket by using winsock library not the MFC library. This solution seems not suitable with my project's scope.

Yep, I'd re-implement CAsyncSocket as well. In fact have done so. But I can't post the code here since it's part of a commercial project.

WSAEventSelect and WSAAsyncSelect are different ways of handling network notifications :

WSAAsyncSelect passes messages to a window which can sit on the main thread of the application. In cases of client/server mechanisms with low load/quick turnaround of functions in server then it should be fine.

WSAEventSelect uses an event-driven mechanism which is window independent. It's designed so you can have threads waiting for network events to be passed through to them - it doesn't rely on windows so you can use worker threads if you wish.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.