"Normal" Request / Response

This is the HTTP protocol itself. It is the client's initiative to make a request to the server. The server will give you an answer. The server can not take the initiative to send information to the client without asking it in the HTTP 1.1 version (I think it has changed in 2).

This is an additional explanation why it works this way

The HTTP protocol is an application-level protocol that uses the TCP protocol as the communication protocol. Communication protocols typically use sockets to transmit data.

So the client and server have to open a socket to send requests and receive responses (respectively). Sockets are bidirectional, that is, they let you communicate in both directions (receive and send).

However, it is possible to close one of the directions if it is not used (as is the case with HTTP). This is why the client can only send requests to the server.

Main difference between two-way and one-way sockets in SOEN

Long-polling and polling

Long-polling

Long-polling is an application-specific behavior. When using long-polling the client is waiting for the server to send a set of data to it.

Imagine that you have a web application server with tasks. Now imagine that the server still does not have any data and a client asks to get a list of All. However, the customer prefers that most of the time this list is not empty.

Then the server is waiting for other clients (or even the same client) to create tasks. And only when there is at least 1 task does it send a response to the client.

However, the server can only "handle" the response for a certain period of time because it is normal for requests to have a maximum timeout (usually this timeout is configurable on the client). This means that long-polling can not give guarantees that there will be a set of data to send (in this case tasks).

Polling

Polling works a little differently. The client is sending requests to the x server at x time waiting for the server to give it new information. The server does not block the waiting for a client to create tasks.

As you mentioned, both long-polling and polling are primitive techniques and do not really give any kind of assurances. (Note that neither polling nor long-polling ensures there will be any new data.)

Web-sockets

Web-sockets is a protocol other than HTTP. Unlike HTTP, it allows bidirectional communication on both the client and the server.

Following the same example of the task application, this means that the server can send a request to the client when it has new tasks. In this approach there is no type of server blocking, nor does the server receive unnecessary requests from customers (who are waiting for new data).

See also an example of a web-scoket javascript client. (working !!)

var ws = new WebSocket("wss://protocols.herokuapp.com/web-sockets");

ws.onopen = function()
{
    // Web Socket is connected, send data using send()
    ws.send("Message to send");
    console.log('Client sent message');
};

ws.onmessage = function (evt) 
{ 
    var received_msg = evt.data;
    console.log("Server sent: " + received_msg)
};

ws.onclose = function()
{ 
    // websocket is closed.
    console.log("Connection is closed..."); 
};

Server-Sent events

This protocol is an HTTP protocol application. But this time it is the server that sends requests (it ends with the limitation of the client not being able to receive requests). Order processing is usually done by registering handlers for events.

See a more detailed explanation of Server-Sent events in SOEN

  var source = new EventSource('https://protocols.herokuapp.com/sse-hello');

  source.addEventListener('message', function(e) {
    console.log(e.data);
  }, false);

See the server code!

WebRTC

WebRTC seems to be a specialized protocol for streaming media (video and audio). This protocol follows a p2p model where clients transmit data between them. This means that the number of requests made to the server containing the resource is minimal.

See a more detailed explanation of WebRTC in SOEN