Is it reliable to use RPC over Internet ? My boss mentioned ISP's will do filtering if they detect a binary protocol being transferred over wire. I still didn't under stand the reason why ISP should block binary protocols. ISP's purpose is to route the packets as soon as possible.
What are the general opinions in using RPC over Internet ? I can have alternatives to use a well known protocol like HTTP or HTTPS and transfer my content over that. But still what are the issues if I just plainly use a binary protocol in a not-so popular port ?
I would say you answered your own question. If some ISP's filter binary protocols then it isn't reliable.
As for why ISP's would block the protocol I don't know.
If you're worried about reliability then use HTTP as you have that available.
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 couldn't find this information on tech specs...
Although REST is very convenient to a variety of scenarios, a native protocol sounds like much more high speed. Does the current implementation support native binary protocol ?
Yes, it's possible to use the native transport protocol.
Nodes connecting via this protocol know the cluster state and routing information which makes them faster. Right now, only the Java client supports this protocol.
Generally speaking we found that the HTTP protocol isn't much slower if you connect with high parallelity. Just connect asynchronously with many connections.
What is the purpose for using sip with VOIP ? is it just to know the remote ip address ?
If i know (by server) the remote IP address ,then established a direct TCP socket connection for call negotiation, and send the media over RTP protocol ,so am i still need sip protocol ? or how can sip help me here?
The Session Initiation Protocol does rather a lot more than find out a remote IP address/port/transport triple.
It lets two parties
negotiate the media streams (including codecs and transports) and
establish commonly understood extensions to the protocol.
It also describes how to build scalable infrastructure (proxies, using SRV and NAPTR records, back to back user agents), location services and a host of other details that go into making a voice (or any other kind of) call to arbitrary third parties.
then you have implemented a sip alternative. sip (session instanciation protocol) does just control the "phone call". if you want to do that on your own, why not? the only problem would be that there are many sip clients and just one (or few) clients using your protocol.
SIP allocates a IP:port to a voip call. The RTP flows (one for each direction) will then use this IP:port as a destination address. If you have only one static RTP flow to send to your server, it may be useful and ok to do what you said.
Otherwise, if there are many clients, or if your system has to change a lot, it's better to use a polished protocol which will dynamically allocate ports and establish your sessions.
nobody forces you to implement a standard.
e.g. why do you implement the media stream in RTP? most likely because you already have code that "talks" RTP (e.g. a library, or a raedymade application).
the nice thing about standards is, that it will work "out-of-the-box" with all other applications implementing the same standard.
if it is an open standard, there's another nice thing: other people have already spent a lot of brain power into getting the implementation right. you don't need to fall into the same problems.
It’s just a start where I am exploring more in P2P side, and finding reasons in terms of Scalability or anything else for : SIP or XMPP (Jingle) for following use case :
P2P Client Application Capable to perform File Transfer on all Network Traversal Scenarios.
// For Signaling (e.g.; to connect/locate/disconnect peers) both XMPP (Jingle) or SIP are available.
May I know possible reasons to use what and why? Any practical use? e.g.; Scalability or anything which really makes a difference for the above Use Case
Jingle is an XMPP extension to handle multimedia sessions. In effect Jingle is the XMPP equivalent of SIP.
As far as a P2P file application goes:
Jingle and SIP are roughly equivalent as far as scalability goes. Both separate the signalling and media providing more flexibility (and consequently complications) with the way server side components can be deployed.
XMPP/Jingle has a better security design making it much more practicable to enforce clients using an SSL signalling layer. SIP does support SSL but it's more convoluted and also doesn't enjoy widespread support in the real World,
As far as NAT goes you're going to have the same problems with both. The scalability you get from having separate signalling and media paths comes back to bite when NAT is involved. There are a few different mechanisms to deal with NAT the latest attempt is ICE. ICE is collection of different mechanisms to try and resolve different NAT configurations and it's worth bearing in mind that not all configurations can be resolved and the fallback is to use a media proxying server such as TURN.
If I was you I'd use XMPP but before starting I'd work out exactly what NAT configurations need to be supported. If you need to support arbitrary clients from anywhere on the internet then you will not be able to rely on always being able to establish direct P2P communications between your clients and that's where you will face your biggest challenge.
I'm building web app that needs to communicate with another application using socket connections. This is new territory for me, so want to be sure that sockets are different than websockets. It seems like they're only conceptually similar.
Asking because initially I'd planned on using Django as the foundation for my project, but in the SO post I linked to above it's made very clear that websockets aren't possible (or at least not reliable, even with something like django-websockets) using the preferred Django setup (Apache with mod_wsgi). Yet I've found other posts that casually import Python's socket module for something as simple as grabbing the server's hostname.
So:
Are they really different?
Is there any reason not to use Django for a project that relies on establishing socket connections with an outside server?
To answer your questions.
Even though they achieve (in general) similar things, yes, they are really different. WebSockets typically run from browsers connecting to Application Server over a protocol similar to HTTP that runs over TCP/IP. So they are primarily for Web Applications that require a permanent connection to its server. On the other hand, plain sockets are more powerful and generic. They run over TCP/IP but they are not restricted to browsers or HTTP protocol. They could be used to implement any kind of communication.
No. There is no reason.
Websockets use sockets in their implementation. Websockets are based on a standard protocol (now in final call, but not yet final) that defines a connection "handshake" and message "frame." The two sides go through the handshake procedure to mutually accept a connection and then use the standard message format ("frame") to pass messages back and forth.
I'm developing a framework that will allow you to communicate directly machine to machine with installed software. It might suit your purpose. You can follow my blog if you wish: http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html
WebSocket is just another application level protocol over TCP protocol, just like HTTP.
Some snippets < Spring in Action 4> quoted below, hope it can help you understand WebSocket better.
In its simplest form, a WebSocket is just a communication channel
between two applications (not necessarily a browser is
involved)...WebSocket communication can be used between any kinds of
applications, but the most common use of WebSocket is to facilitate
communication between a server application and a browser-based application.
You'd have to use WebSockets (or some similar protocol module e.g. as supported by the Flash plugin) because a normal browser application simply can't open a pure TCP socket.
The Socket.IO module available for node.js can help a lot, but note that it is not a pure WebSocket module in its own right.
It's actually a more generic communications module that can run on top of various other network protocols, including WebSockets, and Flash sockets.
Hence if you want to use Socket.IO on the server end you must also use their client code and objects. You can't easily make raw WebSocket connections to a socket.io server as you'd have to emulate their message protocol.
WebSocket is a computer communications transport protocol (like TCP, HTTP 1.0, HTTP 1.1, HTTP 2.0, QUIC, WebRTC, etc.)
Socket is an endpoint for sending and receiving data across the network (like Port number)
Example of Socket:
(TCP, 8.8.8.4, 8080, 8.8.8.8, 8070)
where:
(protocol, local address, local port, remote address, remote port)
Regarding your question (b), be aware that the Websocket specification hasn't been finalised. According to the W3C:
Implementors should be aware that this specification is not stable.
Personally I regard Websockets to be waaay too bleeding edge to use at present. Though I'll probably find them useful in a year or so.