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
Related
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.
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.
I want to know how two computers with VoIP software can be connected to each other and exchange voice data without having an external IP address.
You would need an static IP address only if you were trying to connect the two to each other directly. The VOIP server acts as a go-between.
Example:
Person 1 and Person 2 are trying to get into a VOIP call
They both register with the VOIP server with their IDs.
When one ID places a call to another, the there is a connection between the two, with the server in between, but not directly with each other.
SIP (Session Initiation Protocol) is usually the Protocol used for VOIP. There is a SIP registrar, which is the server. You can establish your own SIP server using Asterisk's free solution. SIP actually makes it possible to directly connect peers. However, this isnt possible over the internet where people dont have static IPS
Software like skype use a similar workflow. The skype client tries to connect the peers. When it cant, it uses something like UDP Hole Punching.
Every computer in the internet has an external IP.
The internet works that way.
There are numerous pages on the internet, where you can see your 'external IP'.
Regarding the voice exchange: They connect to a server and that server either does the relaying himself, or exchanges the IP information between the clients, who are then left to create a connection among themselves.
The actual data of a VoIP call is carried over RTP, which really only takes 24-64Kbps (depending upon codec) and requires UDP addresses going each way. Occasional RTCP packets are sent to report status, metrics, etc, but are not really needed.
SIP is used for call setup and teardown.
There is always a network address between two VoIP endpoints, comprised of the IP address and the VoIP socket.
And yes, you could proxy RTP over some other transport protocol, or tunnel (through http?), etc.
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 was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
Check out Real-Time Media Flow Protocol and how they use it.
Check out UDP Hole Punching
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.