Is it possible to initiate a TCP connection request with overlapped I/O, and cancel it before the connection has been completed in Windows? I need to support at least Windows XP SP2.
ConnectEx allows an overlapped connection attempt.
To cancel this one would need to use CancelIo passing the SOCKET as if it were a HANDLE (it is really). But this must be done from the same thread that called ConnectEx. Managing things so you can achieve that thread specificity is unlikely to be easy.
After XP/2003 (ie. Vista/2008/8/2008R2) you can use CancelIoEx from a different thread (the OVERLAPPED instance is used to fully identify the IO operation).
From here:
overlap
This directory contains a sample server program that uses overlapped
I/O. The sample program uses the AcceptEx function and overlapped I/O
to handle multiple asynchronous connection requests from clients
effectively. The server uses the AcceptEx function to multiplex
different client connections in a single-threaded Win32 application.
Using overlapped I/O allows for greater scalability.
Related
I'm trying to understand if ZeroMQ can connect pub or sub socket to non existing (yet) ip address. Will it automatically connect when this IP address will appear in the future?
Or should I check up existance first before connecting?
Is the behavior same for PUB and SUB sockets?
The answer is buried somewhat in the manual, here:
for most transports and socket types the connection is not performed immediately but as needed by ØMQ. Thus a successful call to zmq_connect() does not mean that the connection was or could actually be established. Because of this, for most transports and socket types the order in which a server socket is bound and a client socket is connected to it does not matter. The ZMQ_PAIR sockets are an exception, as they do not automatically reconnect to endpoints.
As that quote says, the order of binding and connecting does not matter. This is extremely useful, as you don't then have to worry about start-up order; the client will be quite happy waiting for a server to come online, able to run other things without blocking on the connect.
Other Things That Are Useful
The direction of bind/connect is independent of the pattern used on top; thus a PUB socket can be connected to a SUB socket that has been bound to an interface (whereas the other way round might feel more natural).
The other thing that I think a lot of people don't realise is that you can bind (or connect) sockets more than once, to different transports. So a PUB socket can quite happily send to SUB clients that are both local in-process threads, other processes on the same machine via ipc, and to clients on remote machines via tcp.
There are other things that you can do. If you use the ZMQ_FD option from here, you can get ZMQ_EVENT notifcations in some way or other (I can't remember the detail) which will tell you when the underlying connection has been successfully made. Using the file descriptor allows you to include that in a zmq_poll() (or some other reactor like epoll() or select()). You can also exploit the heartbeat functionality that a socket can have, which will tell you if the connection dies for some reason or other (e.g. crashed process at the other end, or network cable fallen out). Use of a reactor like zmq_poll(), epoll() or select() means that you can have a pure actor model event-driven system, with no need to routinely check up on status flags, etc.
Using these facilities in ZMQ allows for the making of very robust distributed applications/system that know when various bits of themselves have died, come back to life, taken a network-out holiday, etc. For example, just knowing that a link is dead perhaps means that a node in your distributed app changes its behaviour somehow to adapt to that.
Is it possible on Windows 7 to write a C++ or .NET program that finds out whether an existing, connected TCP socket created by another program has any data in its send or receive buffer?
Use case: There's a 16-bit legacy application doing TCP communication with some .NET applications. To work around a concurrency issue in the legacy app, it would be helpful if we could inspect either of two sockets that are connected to each other and tell whether there's some data sent on one end but not yet received on the other end.
The connection is TCP and the sockets are on the loopback interface (127.0.0.1).
Approach: WSADuplicateSocket() + WSAPoll() could be the solution but I don't know how to get a hold of the socket handle programmatically because the socket is created by another program.
We have a legacy vb6 automation application that communicate over a sockets on need basis.
But opening and establishing connection (only when required) to the remote port taking more time frequently.
So,i am planning to write other application (say a socket server) that opens the required sockets and keep the connections alive.This application will write connected socket handle values to a file or database.
Is it possible in vb6 to create a socket object using socket handle from the already opened socket that was owned by other process (socket server application in this case)?
This is exactly the type of situation that WSADuplicateSocket() is intended for.
Your "server" can create a socket and use WSADuplicateSocket() to fill a WSAPROTOCOL_INFO record that describes the socket. The "server" can then expose the WSAPROTOCOL_INFO to your VB app using any IPC mechanism you want. The VB app can pass the WSAPROTOCOL_INFO to WSASocket() to access the socket and use it as needed.
No, Windows sockets cannot be shared cross-process, not even through handle inheritance (this is because although it is usually a handle, an LSP might return something that is not a handle and thus not inherited). You should make one process open and maintain the connection and the others talk to that process to communicate with the server.
I'm making a sniffer using LSP/SPI for specified application. But I cant understand how does this application work with network.
There are no "connect" or WSAConnect calls. I intercept WSPRecv, WSPSend, WSPCloseSocket, but no WSPConnect.
Another strange thing - WSPRecv always returns WSA_IO_PENDING, but hEvent in lpOverlapped is null, lpCompletionRoutine is null too. And no calls to WSPGetOverlappedResult (WSAGetOverlappedResult, GetOverlappedResult) and GetQueuedCompletionStatus (GetQueuedCompletionStatusEx). I hooked all this functions, but no calls at all! How does this application recv data?
Can you help me? How does it work? I have missed something?
A parent process listens for connections. Once a connection is established the parent process launches a new child process to deal with the connection. The child process inherits the handle of the connected socket. The child process communicates over the socket and eventually closes the socket and exits.
If you look at the child process in isolation you will see sends, receives and a final close but no initial connection, just as you describe.
This is a more common model on UNIX but it is sometimes used on Windows.
As for the strange overlapped behaviour, this may be what you see if you look at the internals of a non-blocking socket. Non-blocking sockets are implemented on asynchronous sockets, but I don't know the details.
I'm trying to write standard FTP server.
I wonder whether this scenario is correct or not?
1. On each request of clients, a thread manager makes thread for control connection.
2. When control connection thread receives PORT command, it establishes data connection(active open)
Is this usual solution? I wonder this since I have to create standard FTP server.
I would be happy if you answered JUST 'yes' or 'no'.
Thank you in advance.
Yes, FTP uses two connections, read the RFC http://www.ietf.org/rfc/rfc959.txt, the wikipedia article is a bit friendlier http://en.wikipedia.org/wiki/File_Transfer_Protocol but the RFC is the bible.
As far as threads go you will need a thread to listen for incoming connections, a thread to process the control connection and a thread to process the data connection. You could do it all with one thread by using asynchronous i/o using select.