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.
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.
I'm building a distributed system and I would like asynchronous send and recv from both sides with blocking after high water mark.
PUSH/PULL sockets works great, but I wasn't able to bind a PUSH socket. Meaning I can't have a client-PUSH to server-PULL and a server-PUSH to client-PULL, if the client is behind a firewall, since the server can't connect to the client.
In the book, the following is written, but I can't find an example of it.
"REQ to DEALER: you could in theory do this, but it would break if you added a second REQ because DEALER has no way of sending a reply to the original peer. Thus the REQ socket would get confused, and/or return messages meant for another client." http://zguide.zeromq.org/php:chapter3
I only need a one-to-one connection, so this would in theory work for me.
My question is, what is the best practice to obtain asynchronous send and recv with ZeroMQ without dropping packets?
Most ZeroMQ sockets can both bind (listen on a specific port, acting as a server) and connect (acting as a client). It is usually not related to the data flow. See the guide for more info.
Try to bind on your servers PUSH socket and connect from your clients PULL socket.
I'm building a strategy game, where players can battle each other. As for now, I'm focusing on making 1v1 PvP battles, but I also want to build an architecture, that will allow for further extension by up to 3v3 battles.
The game I create is based on socket Client/Server architecture. Every player, that will enter the game and press the "Find match" button, will be placed in a separate battle against one of the other players.
However, I have so many questions about how to structure the sockets:
Do I need a separate socket ("room socket") for each simultaneous battle?
Who should create and bind the room socket? If it's a client, how the server can connect to this socket if the client's ports are closed? If it's a server, see p. 3
Is it possible to bind all of these sockets to one port? How the client can connect to "his" socket if the addresses and the ports are the same?
When and how to open "room sockets" so that each client will get a corresponding endpoint? How to write it on server-side?
How many sockets do I need for matchmaking queue ("welcome sockets")?
Am I to use multithreaded programming, or it is possible to go without it?
I will be grateful for any help with it
P. S. Since the language I'm writing my server on isn't too prevalent, I can't use any ready solutions
From your question I suspect you could benefit from reviewing the Beej Guide to Network Programming.
Do I need a separate socket ("room socket") for each simultaneous battle?
I'm not sure what you mean by a "room" socket. If you mean that a different listening socket will be assigned per game, than that wouldn't be practical.
The normal way to go about is to have the server listen on a single socket (address / port) and each client will connect to the server's socket.
This means that the server will have a socket per active client + a listening socket and each client implementation will have a single socket (the connecting socket).
For a 1:1 game, the sockets can be "matched" to a couplet by the server, making that "couplet" into a room.
For a 1:many game you might consider using a pub/sub pattern by implementing "channels" and "subscriptions"... However, since (I'm assuming) a player can only enter a single game at a time, you might consider making an array or linked list of players per game.
Is it possible to bind all of these sockets to one port? How the client can connect to "his" socket if the addresses and the ports are the same?
Yes, it's possible and this is how servers actually work.
A listening socket behaves slightly different than a connection socket, in the sense that a listening socket can "accept" connections and create a new socket per connection.
When and how to open "room sockets" so that each client will get a corresponding endpoint? How to write it on server-side?
This is language dependent. Most languages have some kind of variation on the functions listen in the Beej Guide to Network Programming.
Generally a server will call listen and than create new client sockets using accept. A client will call connect and have a single socket.
How many sockets do I need for matchmaking queue ("welcome sockets")?
For a 1:1 game you will need a single socket "queued" as it waits for the next available connection.
Of course, this might be more complex. If a client has a game requirement (i.e., only players level 10 and up), you might require an ordered list or another data-store to manage the queue.
Am I to use multithreaded programming, or it is possible to go without it?
You can probably run thousands of games on a single machine with a single thread if you use an evented (non-blocking) design.
This really depends on how much work is performed on the server vs. how much work is performed on the client's computer.
In all the documentations of X11 that I've found so far something like this is written
Communication between server and clients is done by exchanging packets over a channel. The connection is established by the client (how the client is started is not specified in the protocol). (from wikipedia)
I haven't been able to find what is this channel exactly? A network channel for example? Is it on a port? Is it a memory map? Any help is appreciated.
The phrasing of 'channel' is intentionally vague as it can be either over a local socket, a remote connection (such as SSH), a named pipe, or another method that allows client/server bidirectional communication. Which is to say, a 'channel' is simply a connection between two points that facilitates exchange of data.
When perform X11 forwarding over SSH, the channel is the SSH connection. See the SSH man page for example:
$ man ssh
X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel.
or per the x.org documentation:
The communications channel between an X client and server is full-duplex: either side can send a message to the other at any time. This is canonically implemented over a TCP/IP socket interface, though other communications channels are often used, including Unix domain sockets, named pipes and shared memory. The channel must provide a reliable, ordered byte stream---the X protocol provides no mechanism for reordering or resending packets.
X11 support multiple forms of communication between client and server. These so called channels can be TCP sockets, UNIX sockets, and a bunch of other network mechanisms, such as DECnet, token ring etc. TCP and UNIX sockets are really the only ones used today.
The X server is a process that has access to the graphics hardware, keyboard, and mouse. Any application that produces graphics on the computer screen is called a client. Usually, a workstation has on X server running, and multiple X clients. The applications (clients) need to connect to the X-Server via a TCP socket (identified by IP address and port number) or via a UNIX socket (identified by a file name, e.g. /tmp/X0)
If both, server and clients, run on the same system they usually connect through the UNIX socket. However, one of great features of X11 is that server and clients do not have the reside on the same system, but rather connect through the network via TCP sockets. This allows us to run applications on different computers on the network, and bring their graphics output on a single screen. (A single application may also connect to multiple X server and distribute graphics content on multiple screens.)
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.