11 replies to this topic

[Dzhimme]

Hello everyone! As you may see I'm new to this community, and i've got a question.

Can anybody tell me where to learn Asynchronous sockets in c++? Would be nice if you could show me some examples as well. And I don't want to use Boost. Maybe anyone knows any other good networking library?

[hplus0603]

I know of no other cross-platform asynchronous socket library than boost::asio.
If you want to learn asynchronous sockets programming otherwise, you'll have to specify what OS you want it for (BSD, MacOS X, Linux, Windows NT, Solaris, AIX, ...) because they are all different APIs.

[Dzhimme]

I'm going for Windows

[hplus0603]

So, on Windows, "asynchronous sockets" actually means an old way of talking to sockets used in the Windows 3.11 and Windows 95 days, where sockets send messages to the windows message loop. You *really* don't want to be using that, as it's full of bugs and pitfalls, and performs poorly.

"Asynchronous sockets" in the sense of "asynchronous I/O" on Windows is called "Overlapped I/O with I/O Completion Ports." There are some decent explanations and sample code for how this works on msdn.microsoft.com, but you have to dig a bit to find them. Generally, on modern Windows, a socket is a file handle, so you can use ReadFile with an OVERLAPPED struct to post an asynchronous request, for example.

I would recommend using boost::asio, though.

[lonewolff]

Async Client

http://www.win32developer.com/tutorial/winsock/winsock_tutorial_6.shtm

Async Server

http://www.win32developer.com/tutorial/winsock/winsock_tutorial_7.shtm

[Antheus]

Async Client

http://www.win32deve...tutorial_6.shtm

Async Server

http://www.win32developer.com/tutorial/winsock/winsock_tutorial_7.shtm

I really wouldn't use that. It's painfully bound to windows message pipeline and its once-intended use offers no real advantages. Even if it might look sensible for typical Win32 GUI application, such approach makes no sense on headless server.

Async today, for all intents and purposes means IOCP, epoll or kqueue, perhaps through one of common libraries: asio, libevent or ACE. Or just use them directly. Most of these libraries also extend beyond just network to files and possibly DMA transfers (aka fast copying).

.Net's async networking via C# perhaps might be a decent place to start, at least the general concepts transfer and might be easier to experiment with.

And I don't want to use Boost. Maybe anyone knows any other good networking library?

What precisely would "good" mean? asio would be the de-facto C++ networking library. libevent is its counterpart for C. And ACE... it has kitchen sinks.

All of these provide some required functionality that isn't directly available or quite straightforward when using underlying APIs (timeouts come to mind).

[hplus0603]

Async Client
...
Async Server
...

Those are *exactly* the Windows 3.1 APIs that I recommended against using. They are old, perform terribly, have bugs, and are hard to use.

[Dzhimme]

Those are *exactly* the Windows 3.1 APIs that I recommended against using. They are old, perform terribly, have bugs, and are hard to use.

I already started reading on IOCP anyway i saw this tutorial earlier, It's for a Win32 app, I'm making my server in a form of a CMD
Maybe you could suggest me some tutorials/references?

[lonewolff]

You can use this Async Sockets in CMD (console) applications too, you know.

[Sirisian]

Maybe you could suggest me some tutorials/references?

MSDN Documentation is your best bet.
For TCP read the MSDN documentation for: WSASocket, bind, listen, AcceptEx, WSAConnect, WSARecv, WSASend, CreateIoCompletionPort, GetQueuedCompletionStatus
For UDP read the MSDN documentation for: WSASocket, WSARecvFrom, WSASendTo, CreateIoCompletionPort, GetQueuedCompletionStatus

I think those are the major ones. They will lead you to everything else. However, I would recommend using boost::asio. It basically just wraps everything and gives a clean interface to do the same thing in C++.

[Dzhimme]

Nother Question: How much clients would i be able to handle with a Thread-Per-Client implementation?

[hplus0603]

Nother Question: How much clients would i be able to handle with a Thread-Per-Client implementation?

No idea. How about you try it and report back? Note that it depends on the hardware and OS you're using, as well as other parameters.