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.
Related
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.
I wanted to know if anyone has any idea of how I can handle this scenario:
I want to have two terminals open. In one of them I want to run an NS-3 script file which generates packets and sends it through a socket to the other terminal.
The other terminal (which is only running a simple C socket program) receives the packet through the socket (and ideally displays the payload or even simpler increases a packet counter).
Any ideas appreciated...
Yes, you can make ns-3 interact with the real world.
Please read this tutorial :
http://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world
Especially Tap bridge. The Tap Bridge is designed to integrate “real” internet hosts (or more precisely, hosts that support Tun/Tap devices) into ns-3 simulations
http://www.nsnam.org/docs/release/3.18/models/html/tap.html
I currently have a basic chat program in c++ that uses WinSock2.h with UDP. Currently the user is able to send a message to the server and the server just sends the same message back. I was wondering where do I go from here (i'm not asking for code). I was wondering how I should go forward in having the messages get sent to another client that is also connected to the server.
If I need to explain what I have done already please let me know.
All suggestions are greatly appreciated.
Thanks
You would have a list of currently connected users, when a user sends a message, it would then post it to all connected users.
Your server would keep track of who is connected, and remove those who get disconnected. When someone connect or disconnects, it would send a notification to all currently connected users, telling them of this notification.
All this is not specific to UDP, infact, TCP would probably be better for this type of messaging as you do not have to worry about messages being dropped. UDP should only be used where performance is of upmost importance, like real-time gaming, voice chat.
When you're saying "connected" (in the context of clients) - what exactly do you mean?? Because you say you're using UDP in your program.
In the UDP protocol there's no "connected" state, unless you implement it.
In the TCP protocol however, there is (implemented within the protocol itself).
Furthermore, the basic idea of "broadcasting" a message is simple - keep a list of connected clients.
Add a client when it connects. Remove it from the list when it disconnects.
Then when you want to send a message to everyone you just iterate through this list.
Again, you'll have to receive those dis/connect events before you could keep track of "connected" clients.
If you go with TCP instead of UDP then you're set.
Good luck.
Basically, like Matthew said, you need to store all the current connections to the server. When a socket connects you can store a reference to that socket. Now whenever a client sends a message you can rebroadcast that to all the sockets. Now you have to handle when sockets disconnect as well since you don't want to store a bunch of closed sockets.
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.