I am using Overlapped IO, I want to accept client connections using a blocking call, the same way I do with a normal accept(). I am not sure but I think that AcceptEx() does not block, while WSAAccept() does. So is WSAAccept() similar to accept()?
accept() and WSAAccept() will both block unless you've used ioctlsocket to set the listener to non-blocking mode. So you could use either of those to accept a client while blocking.
However you'll gain more control if you use WSAEventSelect to register an event against FD_ACCEPT on your listener. Your event will be set when a client is ready to be accepted without blocking.
You could then combine this event with, say, a timeout or another event that you can signal if you want to cancel the listen (e.g. on application exit) in a call to WaitForMultipleObjectsEx.
Why do you want to use a blocking call?
If you're using I/O Completion Ports then the best way to handle connection establishment is to use AcceptEx() and not wait for data along with the connect. The reason for this is that using AcceptEx() means that you don't need a separate thread to deal with connection establishment (i.e. a normal "accept loop") which reduces unnecessary context switches.
The 'accept and read data' option of AcceptEx() can open you up to a denial of service attack if connections connect and do not send data, and it's hard to guard against it unless you add a housekeeping thread which defeats the purpose of using AcceptEx() in the first place...
Related
Is there a OS portable way of interrupting a blocking accept? I have a multi-threaded deamon/service that needs to gracefully close all listening network hosts when the deamon/service gets a shutdown signal. I see that some say you should use non-blocking sockets or select with a time-out - but won't these degrade performance as my application should be as fast as possible? The deamon runs in the main thread while each of the listening network hosts run in their own thread. The problem now is that accept wait indefinitely if there is no network traffic on the listening network host's socket. If I should use signals, then is there an example somewhere of using signals to interrupt accept?
The solution here is to not call accept when there's nothing to do. Just use non-blocking select or poll to wait until there's something to accept, then accept at that point. Unless you create a really tiny timeout there won't be any performance implications of waking up from the non-blocking call and going back to wait on that socket again.
I use boost:asio::ip::tcp::acceptor to create server socket in my app. I close this acceptor socket using close function, than stop function in io_service but all connected client sockets closes only when my app is closed. How can i fix that?
Thanks!
Do either of the following:
invoke socket::close() on the sockets.
destroy the socket. See this answer for details on how the socket will be closed during destruction.
io_service::stop() only stops processing of the event loop. Work can still be posted into the io_service, and existing work will remain in the io_service. Thus, the application must call socket::close() on each of the sockets it wishes to close. For a portable graceful closure, call socket::shutdown() before calling close().
It may be worth taking the time to review Boost.Asio's HTTP Server 1 example. It uses a connection_manager to shutdown all connections.
I'm trying to communicate between two computers through the TCP/IP protocol on C++. I'm sending and receiving on the same socket. But there is a problem, I have no indicator that the second computer is trying to send me something.
Is there any flag or indicator that tells me that someone is sending something to me and I have to receive?
Use the select() function to wait for an event on one or more sockets. With a zero timeout, you can also check if there is any data available.
That depends on the particular socket API. In the most common case, you just hang on receive (or with async socket APIs you park a callback) and that will unblock as soon as there is data. Some socket APIs have ways for you to tell whether there's data available to fetch, but the simplest way is simply to receive asynchronously and wait for the socket stack to raise the callback on you.
I am faced with a design issue regarding thread synchronization in C++, Windows.
I am writing a server application that starts one listening thread, which should stay active the whole time while the server is up.
When the listening thread gets a connect request, it opens a CONTROL socket and starts a new control thread.
This thread is used to send control data between server and a client, initializing server and all the background software to specific client data and starting data processing.
If the initialization (via control socket) is successful, the control thread will open a new socket, DATA socket, which is then used to pass data from server to client. It will also start two new threads, one which is sending on this new, DATA socket, and the other, which is receiving on the CONTROL socket, waiting if the client wants to terminate connection.
When client terminates connection ungracefully, by terminating application without the call to function which sends the server message to close the connection, here is what should happen:
Any of the threads in execution can detect this event. They will get some sort of error (WSAECONNRESET) while sending or receiving on DATA/CONTROL socket and should then signal all the other threads that they should stop executing (except for the server listening thread).
Which is the most natural way to achieve this type of behavior?
(I am using winsock (winsock2.h) for networking, and standard windows api (windows.h) for threading)
If you're writing a multi-threaded winsock server, you should be looking into IO completion ports. Using an IO completion port is the most scalable way to write a network service on the windows platform.
IO completion port based winsock servers use asynchronous communication, so instead of blocking on a socket, your threadpool receives completion packets when something interesting happens.
In any case, you'll be using WSARecv. When WSARecv returns non zero, call WSAGetLastError(). If you don't have WSA_IO_PENDING, then switch on the error and look for the winsock error code you're interested in.
The winsock error code WSA_OPERATION_ABORTED indicates that a socket has closed, although there are others (e.g. WSAECONNABORTED).
Would suggest a good text on the subject (e.g. Windows via C/C++).
You can use WSAEventSelect() function to associate event object with socket and create one event object for your events, then use these event objects in WaitForMultipleObjects() function, so your thread can wait for socket events and your custom events.
I need a client networking thread to be able to respond both to new messages to be transmitted, and the receipt of new data on the network. I wish to avoid this thread performing a polling loop, but rather to process only as needed.
The scenario is as follows:
A client application needs to communicate to a server via a protocol that is largely, but not entirely, synchronous. Typically, the client sends a message to the server and blocks until a response is received.
The server may process client requests asynchronously, in which case the response to client
is not a result, but a notification that processing has begun. A result message is sent to to the client at some point in the future, when the server has finish processing the client request.
The asynchronous result notifications can arrive at the client at any time. These notifications need processed when they are received i.e. it is not possible to process a backlog only when the client transmits again.
The clients networking thread receives and processes notifications from the server, and to transmit outgoing messages from the client.
To achieve this, I need to to make a thread wake to perform processing either when network data is received OR when a message to transmit is enqueued into an input queue.
How can a thread wake to perform processing of an enqueued work item OR data from a socket?
I am interested primarily in using the plain Win32 APIs.
A minimal example or relevant tutorial would be very welcome!
An alternative to I/O Completion Ports for sockets is using WSAEventSelect to associate an event with the socket. Then as others have said, you just need to use another event (or some sort of waitable handle) to signal when an item has been added to your input queue, and use WaitForMultipleObjects to wait for either kind of event.
You can set up an I/O Completion Port for the handles and have your thread wait on the completion port:
http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx
Actually, you can have multiple threads wait on the port (one thread per processor usually works well).
Following on from Michael's suggestion, I have some free code that provides a framework for IO Completion Port style socket stuff; and it includes an IOCP based work queue too. You should be able to grab some stuff from it to solve your problem from here.
Well, if both objects have standard Windows handles, you can have your client call WaitForMultipleObjects to wait on them.
You might want to investiate splitting the servicing of the network port off onto its own thread. That might simplify things greatly. However, it won't help if you just end up having to synchonize something else between that new thread and your main one.