Ive build a local multiplayer game (multiplayer over wlan network). Now, I want to add an online multiplayer feature..
Currently, the network communications consist mostly of "signals" (tcp/udp packets sent from game-host peer to the game-client peers). I would like to use this mostly signal based communication for my online multiplayer (because of performance and efficiency ), too . But, since the host peer is now replaced by a server there will be a lot problems with sending signals (NAT, firewall,...).
So is there good solution to implement these signals?
regards
there will be a lot problems with sending signals (NAT, firewall,...)_
What problems exactly?
Normally, the clients establish a TCP connection to the server and the server uses this TCP connection to communicate with the clients.
For UDP-based communication the clients use Internet Gateway Device Protocol to forward ports on the router, so that the server can send UDP datagrams to the clients.
Assuming your server is in public internet, not behind any NAT. All the clients must initiate the connection. Otherwise the server can't know clients credential and can't connect. As the server has no NAT it will accept connection from client. And this connection client must keep alive. So when server needs to send some data there should be no problem.
This will work for both UDP and TCP.
Related
if when i try to connect with webRTC from outside the local network, it uses a STUN server to exchange info like ip address, port..., and then once the two clients know each other they will directly connect, but the thing is, if any router by default blocks any port that's opened exept for 80, then how do the two clients connect, on what port?
WebRTC is an open framework and does not dictate how the connections are established between the communicating peers. Establishing the connection itself involves the following.
1-The peer discovery is made via Signaling for doing SDP exchanges and exchanging remote host identities. The Signaling can be done over any transport – UDP/TCP, any protocol and via any standard (SIP/XMPP) or custom application level protocol over HTTP/WebSockets etc. The choice of Ports for signalling traffic is left open to the application developer.
2-Once the peer discovery is complete, and the PeerConnections are established at each endpoints, the media data can be sent. Depending on the network topology of the Peers (whether they are in the same host network, or they are in different network (behind Nated IP address), they can choose to connect such that the media traffic is sent over UDP or over TCP. For a more protected environment, the peers may even need a TURN server to relay the media traffic on Peers behalf. Here again, the choice of Media Ports is left open and can be decided via the end application.
I found this on web I hope its helpful
I'm currently developing a "node-based" system where a server will send out a UDP broadcast on the private network (with a custom protocol), which will be received by several different clients which supports the specified protocol. The server will after the request pick between some of the clients for a more steady TCP connection.
Request for client sequence
Server broadcasting a request-for-ip message to every device/node on the network.
All available clients that supports the protocol will answer with their unique IP to the server.
Server chooses among the clients via a request-for-connection message.
Client that got choosen by the server connects to the server via TCP for a reliable connection.
My question
I've got pretty good knowledge about both TCP and UDP, but I've never designed a system like this before. Do you think this system is built in the right way or is there a more "standard" way doing something similar to this? What are your thoughts?
Thanks!
--- Edit ---
Added a diagram of the program.
There is a standard protocol to advertise services on the network, which you may like to consider: Simple Service Discovery Protocol, based on periodic UDP multicast:
The Simple Service Discovery Protocol (SSDP) is a network protocol based on the Internet protocol suite for advertisement and discovery of network services and presence information. It accomplishes this without assistance of server-based configuration mechanisms, such as Dynamic Host Configuration Protocol (DHCP) or Domain Name System (DNS), and without special static configuration of a network host. SSDP is the basis of the discovery protocol of Universal Plug and Play (UPnP) and is intended for use in residential or small office environments.
In this protocol clients join that UDP multicast group to discover local network services and initiate connections to them, if they wish to. And this is pretty much the intended use case for the protocol, which is somewhat different from your use case.
One benefit of IP/UDP multicast is that multicast packets can be dropped in the network adapter if no process on the host has joined that multicast group. Another one is that IP/UDP multicast can be routed across networks.
From the diagram you posted:
The server is the mediator (design pattern) whose location must be known to every other process of the distributed system.
The clients need to connect/register with the server.
Your master client is a control application.
It makes sense for the server to advertise itself over UDP multi-cast.
Online clients would connect to the server using TCP on start or TCP connection loss. If a client terminates for any reason that breaks the TCP connection and the server becomes immediately aware of that, unless the client was powered off or its OS crashed. You may like to enable frequent TCP keep-alives for the server to detect dead clients as soon as possible, if no data is being transmitted from the server to the clients. Same applies to the clients.
All communications between the server and the clients happen over TCP. Otherwise you would need to implement reliable messaging over UDP or use PGM, which can be a lot of work. Multicast UDP should only be used for server discovery, not bi-directional communication that requires reliable delivery.
The master client also connects to the server, possibly on another port, for control. The master client can discover all available servers (if there is more than one) and allow the user to choose which one to connect to.
I want to connect two clients (via TCP/IP sockets). The clients can discover each other using an intermediate server. Once the clients discover each other, there should not be any involvement of the server.
I made some study about this and found many people suggesting JXTA. But I'd like to create the protocol myself from scratch (because in future I might have to implement the same using WebSockets as well (when my client is a Browser)). Currently, my clients can be Desktop applications or mobile applications.
My questions are:
How will clients discover each other at the server? If the server sends the global IP address of the clients to each other, will that information be enough to create a peer-to-peer connection? What if the clients are on the same LAN network and the server is on a different WAN?
Client have dynamic IP address. Can their IP change all of a sudden even if it has an active socket?
Is peer-to-peer connection is reliable for transfer of non-continuous data (like in chat application)?
[NOTE: by peer-to-peer connection I mean establishing a client-server TCP/IP socket connection (using Java) by making one of the client as temporary socket-server]
Thanks in advance.
1) When the clients connect to the server they will have to notify the server of the port number they will keep open for incoming connections from other clients. The server will know client's IP address. Then the server will need to communicate/send these details to the other party/client. The actual location of the clients does not make any difference. If two clients are on the same network the network routers will find them and make their communication paths shorter.
2) Dynamic IP address can NOT change during active connection - if it does the connection will be dropped and both clients will have to re-initiate the connection through the server in 1)
3) Yes
I've read about WebSockets and I wonder why browser couldn't simply open trivial TCP connection and communicate with server like any other desktop application. And why this communication is possible via websockets?
It's easier to communicate via TCP sockets when you're working within an intranet boundary, since you likely have control over the machines on that network and can open ports suitable for making the TCP connections.
Over the internet, you're communicating with someone else's server on the other end. They are extremely unlikely to have any old socket open for connections. Usually they will have only a few standard ones such as port 80 for HTTP or 443 for HTTPS. So, to communicate with the server you are obliged to connect using one of those ports.
Given that these are standard ports for web servers that generally speak HTTP, you're therefore obliged to conform to the HTTP protocol, otherwise the server won't talk to you. The purpose of web sockets is to allow you to initiate a connection via HTTP, but then negotiate to use the web sockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream.
Web browsers operate at the Application layer, whereas TCP operates at the Transport Layer. As a web application developer, it's easier to send messages over the wire via the Application Layer instead of raw bytes at the Transport Layer.
Underlying WebSockets is TCP, it's just abstracted away for simplicity.
Websocket is a application layer protocol while TCP is transport layer protocol. At transport layer, we usually have TCP and UDP protocol. Any message from application layer need to go through transport layer to be transmitted to other machine. Hence, websocket and tcp have a relationship to each other and can not be comparable.
To make it simple, the websocket communications are done over TCP port number 80 (or 443 in the case of TLS-encrypted connections), which is of benefit for those environments which block non-web Internet connections using a firewall.
Would you like to use existed TCP port or open a new TCP port that might be blocked by firewall?
The socket API is the de-facto standard for TCP/IP and UDP/IP communications (that is, networking code as we know it). However, one of its core functions, accept() is a bit magical.
To borrow a semi-formal definition:
accept() is used on the server side.
It accepts a received incoming attempt
to create a new TCP connection from
the remote client, and creates a new
socket associated with the socket
address pair of this connection.
In other words, accept returns a new socket through which the server can communicate with the newly connected client. The old socket (on which accept was called) stays open, on the same port, listening for new connections.
How does accept work? How is it implemented? There's a lot of confusion on this topic. Many people claim accept opens a new port and you communicate with the client through it. But this obviously isn't true, as no new port is opened. You actually can communicate through the same port with different clients, but how? When several threads call recv on the same port, how does the data know where to go?
I guess it's something along the lines of the client's address being associated with a socket descriptor, and whenever data comes through recv it's routed to the correct socket, but I'm not sure.
It'd be great to get a thorough explanation of the inner-workings of this mechanism.
Your confusion lies in thinking that a socket is identified by Server IP : Server Port. When in actuality, sockets are uniquely identified by a quartet of information:
Client IP : Client Port and Server IP : Server Port
So while the Server IP and Server Port are constant in all accepted connections, the client side information is what allows it to keep track of where everything is going.
Example to clarify things:
Say we have a server at 192.168.1.1:80 and two clients, 10.0.0.1 and 10.0.0.2.
10.0.0.1 opens a connection on local port 1234 and connects to the server. Now the server has one socket identified as follows:
10.0.0.1:1234 - 192.168.1.1:80
Now 10.0.0.2 opens a connection on local port 5678 and connects to the server. Now the server has two sockets identified as follows:
10.0.0.1:1234 - 192.168.1.1:80
10.0.0.2:5678 - 192.168.1.1:80
Just to add to the answer given by user "17 of 26"
The socket actually consists of 5 tuple - (source ip, source port, destination ip, destination port, protocol). Here the protocol could TCP or UDP or any transport layer protocol. This protocol is identified in the packet from the 'protocol' field in the IP datagram.
Thus it is possible to have to different applications on the server communicating to to the same client on exactly the same 4-tuples but different in protocol field. For example
Apache at server side talking on (server1.com:880-client1:1234 on TCP)
and
World of Warcraft talking on (server1.com:880-client1:1234 on UDP)
Both the client and server will handle this as protocol field in the IP packet in both cases is different even if all the other 4 fields are same.
What confused me when I was learning this, was that the terms socket and port suggest that they are something physical, when in fact they're just data structures the kernel uses to abstract the details of networking.
As such, the data structures are implemented to be able to distinguish connections from different clients. As to how they're implemented, the answer is either a.) it doesn't matter, the purpose of the sockets API is precisely that the implementation shouldn't matter or b.) just have a look. Apart from the highly recommended Stevens books providing a detailed description of one implementation, check out the source in Linux or Solaris or one of the BSD's.
As the other guy said, a socket is uniquely identified by a 4-tuple (Client IP, Client Port, Server IP, Server Port).
The server process running on the Server IP maintains a database (meaning I don't care what kind of table/list/tree/array/magic data structure it uses) of active sockets and listens on the Server Port. When it receives a message (via the server's TCP/IP stack), it checks the Client IP and Port against the database. If the Client IP and Client Port are found in a database entry, the message is handed off to an existing handler, else a new database entry is created and a new handler spawned to handle that socket.
In the early days of the ARPAnet, certain protocols (FTP for one) would listen to a specified port for connection requests, and reply with a handoff port. Further communications for that connection would go over the handoff port. This was done to improve per-packet performance: computers were several orders of magnitude slower in those days.