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.
Related
I have two machines talking to each other over TCP, with Machine A using Machine B's service. Ideally I'd love to use an RPC framework for this. gRPC comes to mind since we already use protobuf.
However, Machine A already uses an external library that wraps TCP sockets for communication, so that the client app code can only send raw bytes (encoded in protobuf) to Machine B. So I wonder if I could adapt the code to working with the gRPC server on Machine B.
gRPC is built on top of http/2, and you can theoretically use any kind of connection (e.g. domain sockets, named pipes) to communicate using gRPC, so it is certainly possible. In fact, at least in go, gRPC uses TCP by default.
If the requirement is only that machine A communicates using TCP sockets, but you can use external libraries, then it should be fairly easy to use the gRPC library of the language of your choice to implement the client/server interaction on top of the raw TCP sockets.
On the other hand, if you can not use the gRPC library, while still possible you would have to implement the gRPC protocol yourself, and possibly the http/2 one as well if you can't use any external library; this would likely be a lot of work, and you may be better off creating a simpler, ad-hoc RPC protocol for your use case.
EDIT
The updated question makes the requirements clearer. If you need to use a specific TCP library, but you can use gRPC on top of that, then I think the difficulty of the task really depends on the programming language.
For instance, in go it would be as easy as creating a wrapper struct, implement the net.conn interface for it, and use it with the withDialer option when creating the client. In c++ it looks like it would be more difficult and entail implementing a custom transport (altough I'm not that familiar with the c++ gRPC API so there may be an easier way)
What are the advantages and disadvantages of using only socket based communication vs a hybrid of REST and socket (using socket only when bidirectional communication is necessary, like receiving messages in a chat).
When I say only socket, I mean that instead of sending a GET request asking for /entities, I'd send update_needed and the server would send a push via socket.
My question is not really about performance, it's more about the concept, like delegate vs block/lambda (using socket would be like the delegate concept and REST is more like block).
It all boils down to what type of application and level of scalability you have in mind.
WebSocket/REST: Client connections?
How to handle CQRS from a client-side perspective
Hard downsides of long polling?
The main reason why I wouldn't use WebSockets in any major project is simply that still many users don't use a modern browser that support them. Namely IE 8 and 9 don't support them and both together still have a market share of over 20 % (Oct 15).
We have an application that connects to a server and sends it position every 15 seconds. Now our client has asked to "upgrade" our current TCP/IP connection into WebSocket. The reason for this is he heard it used less bandwidth and he wants to diminish the 15 seconds to 1 second. (not a public application so battery drain is not really a problem)
I have already done some research and many WebSockets vs HTTP comparisons but only 2 or 3 comparisons of WebSocket vs TCP/IP.
I've already found out that :
WebSockets are basically the same as TCP/IP but TCP/IP works on a lower layer than WebSockets.
WebSockets might use less bandwidth because its protocol might be more efficient than our current protocol.
WebSockets use more resources on the server side.
My question is: is it worth it to change our existing code and make use of WebSockets instead of the good ol' TCP/IP sockets?
As you appear to know already, a webSocket IS built on top of a TCP/IP connection. It's a specific protocol built on top of TCP.
My question is: is it worth it to change our existing code and make
use of WebSockets instead of the good ol' TCP/IP sockets?
If your code already works with a TCP socket and you don't need to interoperate with a browser client and you don't need any specific features built into webSockets, then there is no reason to rewrite perfectly functioning TCP socket code.
We have an application that connects to a server and sends it position
every 15 seconds. Now our client has asked to "upgrade" our current
TCP/IP connection into WebSocket. The reason for this is he heard it
used less bandwidth and he wants to diminish the 15 seconds to 1
second. (not a public application so battery drain is not really a
problem)
Whether or not a webSocket would be more bandwidth efficient than your existing TCP connection depends entirely upon what protocol you're running now on the TCP connection. If your existing protocol is very inefficient, then you would benefit from using a more efficient protocol whether that be webSocket or something else. I'd be surprised if switching to a webSocket would reduce anything from 15 seconds to 1 second unless the implementation of what you have now is just really inefficient.
We could only really comment further on a comparison between the two protocols if we could see exactly how your existing code/protocol works. If what you have now is really bad, then switching to a professionally designed system like webSockets might help you, but there's nothing innate in webSockets that makes them more efficient than some other well designed protocol.
Some of the reasons to use a webSocket over a plain TCP connection with some other protocol on it are as follows:
When you want a browser to be able to connect to you (browsers support plain http requests and webSocket connections - that's it).
When you specifically want the message passing type of paradigm that a webSocket offers and you don't already have a specific protocol to use over TCP (in other words when webSocket saves you from having to implement your own protocol).
When you want to connect to some other type of client that can more easily and quickly use a webSocket connection than it can some other protocol or your custom protocol.
When you're trying to share a port with a web server. By their nature of being initiated via an HTTP connection that is then switched over to the webSocket protocol, webSockets can operate on the same port as an HTTP server (sharing it with the web server).
When you want the interoperability with proxies and other network infrastructure that http and webSockets provide.
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).