I am trying to build a small online game (for the sake of learning) where clients join into the game, play, and leave as they will.
I am thinking of using a TCP socket to handle clients joining and leaving the game and subscribing to a UDP connection on the same socket.
Is this practice used or correct? I am writing this code in c++ with Boost.asio.
Cant figure out why you need UDP at all? Is the game latency-critical? What are requirements?
For education purpose i'd prefer to stick with TCP and implement somewhat working. Then depending on problems/requirements modify it.
I think you had better use an UDP socket to handle client joining and a TCP connection to deal with the game and subscribing.
Related
I am trying to learn network socket programming basics and I can't understand some things. I have assignment to create working MMORPG server-client application where even up to 1000 clients can be connected at same time to server using SFML library. I started with some simple stuff like testing packets, sockets and making simple applications like chat in console and multiplayer tic-tac-toe for other assignment. I heard that using UDP sockets is way to go for real-time applications like games so I am trying to understand how does it work. In TCP Socket I am simply listening to connections, once client connects I can assign him to certain socket and keep listening for connections while I send data and identify him.
I don't know how to identify clients using UDP socket. I am not even sure if my approach is right.
I thought that it should work like this:
1.I create UDP socket binding it to certain port.
2.I am making sure that client got permission to receive data from server.
3.In loop I am receiving and sending packets from/to every client.
4.If client get disconnected, we close connection for him/delete him from vector of clients.
So how I do this with UDP sockets? Are they necessary for this kind of architecture ? Also I would appreciate any good article about making working client-server application with good protection and performance. Thanks in advance :)
Okay so I found actually two good articles about using UDP sockets and overall network in game:
SFML Game Development by Example: https://www.packtpub.com/game-development/sfml-game-development-example
Author is writing 3 SFML games in C++ and explains everything as he goes, using UDP sockets and taking care of packet reliability included.
Gaffer on Games article: http://gafferongames.com/networking-for-game-programmers/
Big amount of informations about game networking.
I hope that it helps for someone looking for clues about UDP sockets and examples of using it in network game development.
I am designing a cross-platform messaging service as a learning exercise. I have programmed socket-based servers before, but always a "client-polls-server" design, like a web server. I want to be able to target mobile platforms, and I read that polling is a battery drain, so I would like to do push notification.
The server will be TCP-based, written in C++. What I'm having trouble getting my head around is how to manage the bi-directional nature of the design. I need a client to be able to send packets to the server as normal, but also listen for packets. How do I mitigate situations like, the client is sending data when the server is trying to send to it, or it's blocked listening for data but then needs to send something?
For example, consider the following crude diagram:
So, let's say client A is in the middle of sending a chunk of data (arrow 1). While this is happening, client B sends a message (arrow 2), which causes the server to attempt to send data back to client A (arrow 3), but client A hasn't finished sending arrow 1 yet. What happens in this instance? Should I setup 2 separate ports on each client, one for inbound, one for outbound? Do I need to keep track of the state of each connection?
Or is there a better approach to this altogether?
One socket port is inherently bidirectional. To handle both inbound and outbound traffic more or less concurrently you need to use nonblocking sockets.
I think the solution is pretty simple. The TCP server should have a list with connected clients. Since a TCP connection is bi-directional, the push mechanism is quite simple.
Another important thing, as long as your server isn't multithreaded, you can read from or write to one client at the same time.
Dear Stackoverflowers,
I am researching networking a bit and I decided I'd like to create a small and simple networking library with Winsock. (I am using Completion Ports and Overlapped IO though)
As I researched a bit I came to the following steps for a TCP Listener(Correct me if I am wrong):
Create a Listening Socket
Bind it to a port/IP
Listen on it
When a new connection is created, give a seperate Socket for that connection.
Listener continue's to listen, the specific connection is handled as needed.
EDIT: With a 'connection' from here I mean communication between the server and distinct clients.
Though for an UDP Listener we need to make use of WSARecvFrom which returns the IP address at the lpFrom parameter. Now I was wondering the following:
Is it better to make one UDP Socket listen to incoming connections on a specific port with WSARecvFrom and create new sockets for every specific connection? Or could I just use the UDP Socket itself with WSASendTo. Would that cause any performance penalties if one UDP Socket is used for for example 1000 connections? Or would it be the same or even better then creating/duplicating seperate Sockets for each different incoming connection?
Note: If multiple sockets are needed how would you handle sockets listening on the same port or could a client accept UDP from different ports?
Hope you guys can help!
Ps. Extra tips are always welcome!
Unlike TCP, UDP is connection-less, and as such you don't need to create separate sockets for each party. One UDP socket can handle everything. Bind it to a local IP/Port and call WSARecvFrom() once, and when it reports data to your IOCP you can process the data as needed (if another thread if needed) and then call WSARecvFrom() again. Each time new data arrives, you have to look at the reported lpFrom address to know the IP/Port of the sender. And yes, you can use the same UDP socket for sending data to each sender when needed.
I have a certain application running on my computer. The same application can run on many computers on a LAN or different places in the world. I want to communicate between them. So I basically want a p2p system. But I will always know which computers(specific IP address) will be peers. I just want peers to have join and leave functionality. The single most important aim will be communication speed and time required. I assume simple UDP multicast (if anything like that exists) between peers will be fastest possible solution. I dont want to retransmit messages even if lost. Should I use an existing p2p library e.g. libjingle,etc. or just create some basic framework from scratch as my needs are pretty basic?
I think you're missing the point of UDP. It's not saving any time in a sense that a message gets faster to the destination, it's just you're posting the message and don't care if it arrives safely to the other side. On WAN - it will probably not arrive on the other side. UDP accross networks is problematic, as it can be thrown out by any router on the way which is tight on bandwidth - there's no guarantee of delivery for it.
I wouldn't suggest using UDP out of the topology under your control.
As to P2P vs directed sockets - the question is what it is that you need to move around. Do you need bi/multidirectional communication between all the peers, or you're talking to a single server from all the nodes?
You mentioned multicast - that would mean that you have some centralized source of data that transmits information and all the rest listen - in this case there's no benefit for P2P, and multicast, as a UDP protocol, may not work well accross multiple networks. But you can use TCP connections to each of the nodes, and "multicast" on your own, and not through IGMP. You can (and should) use threading and non-blocking sockets if you're concerned about sending blocking you, and of course you can use the QoS settings to "ask" routers to rush your sockets through.
You can use zeromq for support all network communication:
zeromq is a simple library encapsulate TCP and UDP for high level communication.
For P2P you can use the different mode of 0mq :
mode PGM/EPGM for discover member of P2P on your LAN (it use multicast)
mode REQ/REP for ask a question to one member
mode PULL/PUSH for duplicate one resource on the net
mode Publish/subscribe for transmission a file to all requester
Warning, zeromq is hard to install on windows...
And for HMI, use green-shoes ?
i think you should succeed using multicast,
unfortunately i do not know any library,
but still in case you have to do it from scratch
take a look at this:
http://www.tldp.org/HOWTO/Multicast-HOWTO.html
good luck :-)
I want to play that Qbasic Gorillas game with someone that lives in Florida.
Here's the flash version online
Gorillas
This link is to someone's post about the remake he programmed - there is a link to the game above in there and also his source code for it
playerio.com
If possible, how can I modify the code so that I can play against them over the innernet?
Should the game be public, private, or some combination of both?
It would also be cool if you could replay tosses or entire rounds with their respective angle/velocity inputs.
Take a look at sockets. Sockets are how you can connect two computers over the internet. In most implementations of sockets, you have a server socket and a client socket. The server socket listens for connections, and the client socket tries to connect to a server socket. In your case with just you and your friend, it doesn't matter much which of you is the server or client, but you will have to program for both. You also have to choose a protocol to use. The two protocols for online gaming are TCP and UDP. TCP is the most common and it is a reliable "guaranteed" connection (TCP would send data that is important). UDP is a connectionless protocol where the client just sends data with no guarantee that the data will actually get there. UDP is mostly used for very frequent updates in online games (UDP would most likely be used to send positional data in a first person shooter for example). So with your protocol in mind, I would start by adding a simple chat feature to the game. That way, you can see something working and start to understand what is happening better.
Just to suggest an alternative approach, if you want to play a game that is local multiplayer, you could set up DosBox or a Virtual Machine and then install a VNC server that both of you can log into. This would give you both KVM control.
Since it is a take-your-turn game. you could even use a chat application that has the ability to share keyboard and mouse input.