Is it possible to communicate Client-Server in real time via HTTP?

Asked

Viewed 3,455 times

11

Using TCP sockets I can put a server app on Listening and have clients connect and wait for requests both on the server and on the client, with the possibility of the server sending information to ALL connected clients without any request from the client. To summarize that, I can use a MMORPG for example.

Doubt:

It is possible to do the same type of communication in REAL TIME using HTTP? Or would that be possible only with Websockets? To be more clear: it would be possible to make a MMORPG using HTTP, where customers HTTP (a browser for example, or some HTTP client as the library Httpclient do . Net) connect to the server and make an equal communication in the TCP protocol? The HTTP server being able to send information to all connected clients?

My goal:

Create a SINGLE server Listening in some protocol that I have not yet defined (so doubt) where will be responsible for responding to customer requests and send REAL TIME information to all or X clients of various platforms such as Android, iOS, desktop(browser). As if it were a group chat Facebook or Whatsapp.

NOTE: It would be very enlightening to me how it works (Client-Server communication) Facebook chat and Whatsapp.

  • ai vai alguns dados do Whatsapp http://highscalability.com/blog/2014/2/the-whatsapp-architecture-facebook-bought-for-19-billion.html

  • Says Gustavo, I was generating a question like this and I found yours, I am in the same goal and in the near future who knows how to launch an MMORPG because I like this area Web and games! My question is if you developed the game for browsers, if yes which, and security issues in nevegadores?

4 answers

7


My only real-time experience was with the tutorials of Meteor, and I recommend you take a look - it’s pretty impressive. In minutes you assemble a basic application with HTTP clients (browsers) sharing data in real time. I recommend!


I have little experience, but Phil Leggetter is one of the experts in that area, and in his blog it publishes regularly on the subject. The image below is of your post titled "Choosing your Realtime Web App Tech Stack"

realtime services

Beyond the Meteor, that I already knew, he mentions Sails.js, Socketstream and Derbyjs as "Realtime Frameworks" (He differentiates the Meteor by stressing that it’s not just one framework but a Platform complete).

But the guy’s wild! Check it out:

Of a long list of real-time application building support technologies, he highlights:

Socket.IO

A Node.js library with many ports to other languages.

Faye

Faye is a solution that offers a simple abstraction pub/sub with support fallback complete. This means it will serve the majority needs of a real-time application, and will work in 99% of browsers and network environments.

Another advantage of Faye is that it is available in Ruby and Node.js, and much consideration has been given to security. All you need to build a real-time application ready to go into production.

Sockjs

If you want to work close to the basics of Websockets on client, but also benefit from mechanisms fallback, then Sockjs is a good choice. Sockjs provides a "Javascript emulator Websocket client" and has servers available in Node.js, Erland, Python/Tornado, Python/Twisted and Java. Servers in Ruby, Perl, Go and Haskell under development.

Signaler

Signalr is an open source solution for ASP.NET

Here... I hope to have collaborated with these references. Try the Meteor and... if it doesn’t fit, try the rest. ;-) Good luck!

  • I found this article today, is a tutorial of Meteor: http://www.smashingmagazine.com/2013/06/13/build-app-45-minutes-meteor (build a Meteor application in 45 minutes)

6

Push Technology (Ajax Push)

1. Using connection without "end"

In this technique you can use Ajax leaving it perennial with the server, when receiving the information should treat it and show in the browser. Here Xmlhttprequest must have timeout set to an infinite time and readyState will always be 3 (receiving). The problem here is that the server has no way to control what happens "outside" the browser if the connection falls will be necessary to reload the page.

2. Using a connection pool

This is well used today, here you maintain an Xmlhttprequest connection in the browser, waiting for server response, but renews from time to time, the server can control the connection, javascript (Ajax) should always open a connection when it is "terminated". From a look at BOSH

3. Using Xmlsocket Flash

You can use flash Xmlsocket by interacting with javascript in this way you can keep an active connection to the server since Xmlsocket implements situations that are not present in javascript Xmlhttprequest.

Server-side

The whole problem is here, the server has to support the connections for long time I know the cometd that can be studied for these implementations.

4

Real-time communication with the server is possible.

You quoted something that already allows me to bring you a practical example (.NET)

In the . NET technology was created a real-time service called Signaler, With it you can work in real time. In the link, in the next part below provides several links by Pluralsight with explanations of the functioning of Signalr.

Today in the company where I work, we are studying this technology to put into practice in some projects. It is worth giving a check.

I think it will suit you very well.

Hugs

  • Indeed, Signalr is perfect for this task. Besides having ample support, and being developed by Microsoft.

  • 1

    It is possible to install Signalr via nuget: http://www.nuget.org/packages/microsoft.aspnet.signalr

0

Another option to Signalr, which has some drawbacks, such as not using WebSockets if the server is not using IIS-8, it is xsockets... which creates server-side connections independently of IIS.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.