Using C and the Winsock library (UDP), I made a client-server multiplayer game.
Now I would like to make it so clients can be connected directly to each other (for example in Warcraft III when someone hosts a game the other players connect directly to him), but I do not know and could not find information on how to do this.
For the most part - especially in today's unfortunate world where most clients are behind NAT firewalls and ISPs that block so many incoming connections - client/server programs such as what you're looking to do will route all traffic through the central server, which is "guaranteed" to be accessible from all clients.
Otherwise, you'll want to look into UPnP, and/or something like UDP hole punching to achieve access between clients that may be behind the constraints listed above.
Related
So I have a PC connected to a micro-controller via a serial cable and an Ethernet cable. Initially the PC sends a byte across the serial cable to the micro-controller. This results in the micro-controller sending back a UDP datagram via the Ethernet cable.
I want to know whether the code running on my PC should be a server or a client?
Per Wikiepdia Client/Server:
The server component provides a function or service to one or many
clients, which initiate requests for such services
And Master/Slave:
Master/slave is a model of asymmetric communication or control where
one device or process controls one or more other devices or processes
and serves as their communication hub
The above scenario looks like the Master/Slave. In the initial, 'idle' case, there is no "SERVER" that is waiting ("listening") for requests. Only when the PC activate the micro-controller they will start communication (via UDP).
You could use either term depending on what you were talking about. As other people have noted, client and server are terms used to describe how distinct parties are involved in a service. The terms can be useful in some situations (e.g. a web server and the browser as a client) but in other situations it's a less useful term (e.g. peer-to-peer protocols).
Presumably you're on stackoverflow because you're dealing with code.
In this case it's useful to be more precise and I'd suggest using terms to match whatever primitives are exposed by your language. Most will use/expose Posix sockets as their standard API, and hence you'd want to talk about/use connect or accept (potentially after binding first). Note that these calls work across TCP and UDP (except accept), but the semantics of sending and recving on the resulting connected sockets will obviously be different.
I am not clearly understanding the difference between using TCP socket with client connecting to 127.0.0.1 server address and other IPC such as message queues. Since both are used for communication within the same host, why at all someone would go for socket approach leaving the message queue one, as in this case, sockets will cause more overhead compared to the queues.
The differences that I am seeing:-
In case of sockets we can see the contents in wireshark, in queues there is no such way.
The point of the loopback interface / address is not that you write programs to use it specifically.
The point is that it lets you talk to network services running on the local computer in the same way that you would talk to network services running on a remote host. For instance, if I'm developing a website, I can start up a test instance of its server on my local computer and then point my browser at http://127.0.0.1/ and there it is. I don't have to modify the code of my browser to talk over AF_UNIX sockets or whatever first. Similarly, if I am writing an application that needs a database, I might start out with the database running on the same computer as the application, talking to it over loopback, but then later when the database gets bigger I can move it to a dedicated host and I don't have to change anything other than the connection configuration.
You are absolutely correct that local IPC has lower overhead, and should be used when the two processes that need to communicate will always be on the same machine.
TCP and IPC both approach we use for inter process communication in distributed architecture. If processes are running in same machine we will go for message queue but surely not TCP. But suppose one application is running in one box and another application is running in a different box definitely we have to go for TCP for inter process communication. Even web services also internally implement TCP for communicating to a remote application.
But still we need a TCP base communication in the same machine between two process where synchronize communication is must. For example if you send a request for an account information of a client and waiting for the response you need this approach. But if you just need to send a client information to a server to store it in a table and you don't need an answer from that server whether your records has been stored successfully or not you just go for a queue only to drop the message.
I've come across an interesting problem. Basically I have 2 mobile phones that are both behind NATs. I want to communicate directly between the 2 devices using UDP.
I know if I initiate a connection from the phones to a server then I can push data back down that connection to the phone (ie send it back from the same port that received the message to the same ip and port that it was received from). So I can easily communicate between the 2 devices by connecting both phones to the server. Then sending data to the server and having it re-routed back to the phones. This bypasses any NAT traversal issues I may come up against.
However I would rather just use the server to point the 2 devices at each other and then let them communicate directly. How would I go about doing this? Is it possible without using something like uPnP?
Any help would be much appreicated!
Edit: I found this document http://www.brynosaurus.com/pub/net/p2pnat/ It looks like hairpin translation is what I'm after but it doesn't look to be widely supported. I wonder how good mobile ISP's support for UPnP is?
What you're looking for is UDP hole punching, see e.g. http://en.wikipedia.org/wiki/UDP_hole_punching
The basic idea is simple, you tell each endpoint the ports to use, and they start sending udp packets. The NAT'ing devices will set up a traversal rule when they see the first outgoing packet, and then the next attempt from the other end will match this traversal rule.
You need a mediator server, so the clients can tell where they are. Then one opens a server by uPNP, and the other connects to it.
I would like to create a wireless network from a laptop. If laptops come within range, I would like it to send them a welcome message and send them a goodbye message when they leave the wifi range. Is it possible to do this in C?
Please help me out with this.
It is possible, but it is a very complex task and I don't think that programming language choice is the first thing to look into.
As a start, you can read up on Wikipedia on Wireless ad-hoc networks.
How should your messages be received and displayed on the remote side? If you want to use some existing protocol over TCP/IP, or create your own (deploying custom applications on the remote machines), you will need to mess with networks and this is not always possible as one machine can be a part of only one network. So the machines need to be not connected to anything and somehow allow you to connect to them, it involves changing network settings on all that machines (for example, setting them to join the ad-hoc network with predefined name).
If all machines automatically join the existing network, this question has nothing to do with wireless (physical layer) but with Avahi, Netbios or whatever other services allowing you to get notifications and/or enumerate devices in the network.
Let me explain my scenario before asking the question.
I am in creation phase of 17 different multiplayer games that can be played online, directly from browser.
To accomplish this, I have choosed Silverlight.
Communication will be done using Sockets.
Image 17 different type of games like Chess, Backgammon, Pool and hundred of online users communicating between client app and server app using Sockets binded to the same PORT number.
Wouldn't be faster (for my server) if every different type of game will use another PORT number ? Chess will use 4502, Backgammon will use 4503, Pool 4504.
Will this make a difference ? Or should I use the same PORT number 4502 for all games with no fear that something bad can happen ?
A socket that has been established as a server can accept connection requests from multiple clients. The original server socket does not become part of the connection. The accept method makes a new socket which participates in the connection and returns this socket. The server's original socket remains available for listening for further connection requests.
So it has no advantage to use different server ports. After all web servers get all their requests on port 80 and handle this very well.
As far as speed of processing on your server goes it will most likely make very little difference whether you receive all your communications on one socket or 17. The one socket approach would be a tiny bit faster since your server application will probably have fewer threads to switch between. However there will be other things that will have a higher overhead such as actually processing the game moves or authorising client requests etc.
As for the question of whether to use one or multiple sockets the bigest thing you should think about is deployment constraints. The TCP port numbers that Silverlight is allowed to use a non-standard (i.e not 80 or 443) and if there is a firewall or proxy between your client and server you may be better sticking to a single port to make the access control list on the firewall simpler.