I work in a team that supports mature C++ components that communicate using TCP sockets on Windows. On a LAN this is fine but we want to move the server to the internet and host this for our customers. This isn't a traditional client-server setup because the server can initiate communication. I understand that network administratators would be unlikely to agree to allow a server on the public internet to call into a client behind a firewall so some redevelopment is needed. There seem to be all sorts of ways of proceeding but having little knowledge of comms I find it difficult to decide what options are worth researching. Is there an obviously best way to go?
C# is favoured for new new devellopment over C++.
Related
I'm looking for the name of a protocol and example code that permits handing off IP/port connections to establish unmediated P2P after introduction through a server.
Simple example:
You and I both start chat programs that connect to chatintroduce.com (fictional server). I send you a "Hi! Wanna chat?" message. It doesn't get sent. Instead my chat program tells chatintroduce to send your chat program a request for connection. You respond to a prompt and your chat program tells chatintroduce to broker the connection. Chatintroduce establishes an initial two-way connection between us. Now, this final step is important, chatintroduce releases control and our two chat programs now talk directly to each other without any traffic through chatintroduce.
In other words, I construct packets which have your IP address and you receive them without interference from firewalls, NATs or any other technologies. In other words, true peer-to-peer connection independent of intermediate server.
I need to know what search terms to use to find appropriate technology. An RFC name would suffice. I've been searching for days without success.
I think what you are looking for is TCP/UDP hole punching which typically coordinates the P2P connection using a STUN server to determine the "capabilities" of the firewalls (e.g. is it a full cone nat? symmetric?).
https://en.wikipedia.org/wiki/Hole_punching_(networking)
We employed this at a company I worked for to create a kind of BitTorrent that could circumvent firewalls for streaming video between two peers.
Note that sometimes it is NOT possible to establish a connection without the intermediary.
What you are looking for is ICE protocol. RFC 5245. This protocol is used for connecting two peers through NAT traversal. There are some open source libraries and also some proprietary libraries for this. You can search google with ICE implementation.
You will also need to read about some additional protocols. These are used with ICE protocol. They are STUN and TURN.
For some cases you can't make P2P call 100% time. You will have to use a relay server. Like if the NAT combination of two peers are Symmetric vs Symmetric/PRC. That relay server is called TURN server.
Some technique like Port forwarding and TCP/UDP hole punching will help you to increase P2P rates.
See this answer for more information about which combination of NAT will require a relay server and which don't.
Thank you. I will be looking further into ICE, STUN, TURN, and hole-punching.
I also found n2n which looks like almost exactly what I wanted.
https://github.com/meyerd/n2n
http://xmodulo.com/configure-peer-to-peer-vpn-linux.html
With n2n, one makes a VPN with a super node that all other edge nodes know.
But once the introductions are made, the super node can be absent.
This was exactly what I wanted. I hope it works across platforms (linux, MacOS, Windows).
Again, I am still researching before implementation, so your advice was very important to me.
Thank you.
Use PJNATH. Its open source.
http://www.pjsip.org/pjnath/docs/html/
There is not much open source on NAT Traversal. As far as I know PJNATH is good.
For server you can use Google's Open source STUN and TURN server.
I am having a hard time figuring the motivation behind websockets. From what I've read around the web, regular sockets are still faster and more efficient, so in short, why would I want to use websockets, when and where?
And regarding why to bother with websockets:
It's mainly because browsers only support the Websocket API in their Javascript APIs and do no provide direct TCP socket support.
This was done to prevent (possibly malicious) Javascript apps to create any kind of TCP connections which could provide them confidential information and forward it to the internet.
With Websockets Webapps can only connect to websocket servers. The websocket protocol uses an obfuscation mechanism that prevents that webapps can send any kind of raw TCP data.
Sockets are a lower level. They can work with any type of netwroking. Websockets are at a higher level. They power web servers, and drive web apps. A websocket can be made via plain sockets. It is jsut a lower/higher level thing. Websockets are more of a convience thing. They require you to write less code
At the bottom, it's all about socket communications. If there is some way to get the ip of the both users, why can't the connection be directly setup between the users instead of having to go thru a server in the middle?
My 2 cents:
No one out there forces us to have a server based real-time communication model. Infact XMPP have an extension called "Serverless Messaging" which defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports.
P2P chat applications have been for over a decade now. Having a server in the middle is purely a decision dependent upon your application needs. If your application can live with chats getting lost while the user was transitioning between online/offline status, then you can very well have a direct P2P model going. Similarly, there are a loads and loads of advantages (contact list management, avatars, entity discovery, presence authorization, offline messages, ....) when it comes to choosing a server based messaging model. If you try to have all this right inside your P2P based clients, they might die or under-perform because of all the work they will need to perform by themselves.
"WebSockets" were not designed for P2P/Serverless communication, rather they were designed to provide a standardized PUSH semantic over stateless HTTP protocol. In short, "WebSockets" is a standardized way replacing hacky comet, long-polling, chunked-encoding, jsonp, iframe-based and various other technique developers have been using to simulate server push over HTTP.
Named WebSockets (if someday it is fully and widely supported) could be the solution.
http://namedwebsockets.github.io/spec/
Named WebSockets are useful in a variety of collaborative local device
and local network scenarios: Discover matching peer services on the
local device and/or the local network.
Direct communication between users is possible in Peer To Peer (P2P) networks. In P2P each participant can act as client as well as server. But for P2P networks you need to write a separate program to make the communication possible.
Web Sockets let you leverage existing common browsers as clients. All depends on what is the purpose of your application and how you want to deploy it.
If there is some way to get the ip of the both users
You nailed the answer right in your question.
Most machines I use have IP address of 192.168.0.10 (or similar from 192.168. private network) and are deep, deep behind several layers of NAT. With the end of free IPv4 address pool and IPv6 nowhere near sight, this is the reality most users live. Having a stable intermediary of known, routable address helps a ton working around this issue.
WebSockets don't allow the socket to listen for connections, only to connect as a client to a server (not reverse). Technically they could make it allow this, but as far as I understand the spec doesn't currently (nor is it expected to) allow listen functionality for WebSockets.
The new WebRTC (http://www.webrtc.org/) spec looks like it might support peer-to-peer connections. I have not played with WebRTC at all so I'm not in a position to comment on it. I think it would be a bit more involved than WebSocket stuff. Maybe someone who knows WebRTC better can chime in. (Also apart from the latest version of Chrome I'm not sure if any of the other browsers really support WebRTC yet).
This is my first experience with P2P and i need some help regarding the design.
I am developing a simple messenger application. I have a directory server on which every user authenticates and announces an open port on which every user is reachable. The directory server maintains the users and the ports and I can query the directory server for any specific user. This part is done. The second part is the chat which i think should be P2P. I can start a chat as well as I can be end point of a chat (client as well as server)
What is confusing me is how do I deal with P2P? Do I create two different sockets? One on which I am listening for TCP requests for incoming connections and another one from which I would send TCP requests to start chat.
In this case do I need 3 sockets, one to talk with server and two for P2P?
If you want to go P2P, you'd better use a framework, such as JXTA for example if you are coding in Java. Creating sockets may not be enough by itself, because there are more complicated issues you need to deal with such as NAT traversal if you are operating beyond your LAN.
It seems like you have a central peer (some of server). If it has a public IP address, then you could implement a TURN-like architecture (peers communicate via this central peer). If you want direct connection between peers, you are looking a STUN solutions, but you still need a central peer to facilitate the communication.
TCP Stun is not easy. UDP is not very complicated, you just need to punch a hole in your NAT. Now, keep in mind that NAT traversal is not always possible (it depends of the NAT itself). In this case, the backup solution in a STUN one.
Which is the best solution to communicate bidirectionally between a
remote server and a client behind an internet box?
UPnP with Sockets.
HTTPS/Database Server and the client make 1 request every Xsec to know
if there is new data.
Client opens 1 connection on the server and it maintains open to make a
tunnel.
It totally depends on the application (though you can immediately rule out UPnP, which is an ugly hack suitable for local networks only.) Start reading about the Internet foundation set of protocols - the TCP/IP, pick up the Stevens book - you will get a much better understanding of your options.