50

Those two technologies have a very different purpose. REST is for ordinary calls to an API, with client being an active actor of the exchange. When the client needs to find GPS coordinates of an address, the client initiates the call to the API and waits until it receives the coordinates, or a error occurs, or a timeout elapses. Web sockets are for ...


14

One of the core design goals of Websockets is that it allows both HTTP and Websocket protocols to be communicated over the same port. It achieves this by explicitly requiring a client to perform a Websocket handshake with an HTTP Upgrade request. In this way the server can handle a standard HTTP request connection as well as an HTTP Upgrade request that is ...


13

Section 10.3 of the RFC explains exactly why masking is required. It's a very specific response to a specific hacking technique. The problem it is trying to address is described in a 2010 paper called Talking to Yourself for Fun and Profit by some of the sharpest Internet transport security folks. Client-to-Server masking is used by the Websocket protocol ...


10

How to structure the data that is sent from the server to the user? Use the messaging pattern. Well, you're already using a messaging protocol, but I mean structure the changes as messages... specifically events. When server side changes, that results in business events. In your scenario, your client views are interested in these events. The events should ...


7

Rooms are a tool in socket.io servers for keeping track of groups of connected users. You can then iterate the sockets in a room or broadcast to all of them. There's really nothing more to them than that. The server can put a socket into a room or remove one from a room. When a socket disconnects, it is automatically removed from all rooms it is in. ...


5

Communications do not usually only go one way. Parties usually communicate using request-response pairs, which are clearly not one way. I presume that you already know this, so what you are probably thinking when you say "one-way" is not how information flows, but who initiates the requests. So, yes, the way we usually do things is that only one of the ...


5

You're not seeing requests because it's not making any; the page is maintaining an open Web Socket connection to the server, and the updates are being pushed from the server to your browser, rather than downloaded at your browser's request.


5

webSocket is implemented in browsers (not in the underlying OS). It is built on top of TCP/IP which comes from the OS. You can see which versions of which browsers support webSockets here:http://caniuse.com/#feat=websockets


5

If you simply want to remove AJAX in favor of Web Sockets, there must be one problem: what if the client doesn't support Web Sockets? If, on the other hand, you keep AJAX requests if there is no active Web Sockets connection, and use Web Sockets otherwise, then it might make the architecture more difficult to follow. More code written means more code to ...


5

It looks like Autobahn fits nicely with what you're trying to do. There are other tools available as well. Check out the Windows Azure Service Bus (which has client frameworks for Java, .NET, PHP, Python, NodeJS, and Ruby). While the built in rest messages are useful. You'll find that your application will outgrow basic CRUD operations. For instance if your ...


5

If you have the connectivity, go with a message queue - although you have to define your own protocols (hardly a difficult task!) to send messages of a particular structure and format. The problem with maintenance is that typically the client and server are built separately so you need to be careful to keep both ends using the same message definitions, but ...


4

600 persistent connections should not be an issue - in general connecting overhead is high compared to idle connection overhead(especially if using secure, handshake-based protocol such as TLS), so keeping connections open rather than closing and opening them upon actions definitely reduces the amount of load on the server(and the network, for that matter). ...


4

Yes ...see the link below for this pattern... If you're writing an application which uses Peers -- or any complex app which requires robust Object-Networks I would use an Event-Driven Architecture. Using a Mediator or EventHub (Event-Aggrigator) The simplest approach would be to implement the Mediator Pattern designed by Addy Osmoni. This allows you to ...


4

You want a connection pool - 100 clients will be throttled to using a pool of a handful of DB connections so your DB will not get overloaded responding to many simultaneous requests. You could try to optimise the calls but you will still need to allow the clients to access the DB through a mechanism identical to a connection pool, even if there is just 1 ...


4

If you would like to split it up into several classes, the Java approach is exactly how you would approach it. class Socket method getInputStream returns InputStream method getOutputStream returns OutputStream other methods that apply to the Socket itself and not permitted to be individually controllable by the input aspect or the output aspect alone. In ...


4

After a few months of work on the backend mainly, I have been able to use some of the advices here to address the problems the platform was facing. The main objective when rethinking the backend was to stick as hard as possible to CRUD. All the actions, messages and requests scattered around many routes were regrouped into resources that are created, ...


4

The following questions may influence your choice: how long the server needs to compute its result ? is the result for a unique request or is it broadcasted to several requesters ? how large is the data (payload) to be pushed ? are the clients always interested in all the results pushed ? can some results be lost, or must data always be delivered ? ...


4

According to this research paper: HTML5 Connectivity Methods and Mobile Power Consumption, you do consume a significant amount of energy maintaining an inactive websocket, because it is sending frequent messages back and forth to keep the connection alive. Ideally, you would send data at an interval where the websocket could utilize power-saving mechanisms ...


4

Creating a new connection is expensive in terms of resources. The goal of WebSocket is specifically to avoid creating connections on regular intervals, such as in the case of long polling. However, maintaining an open connection is also expensive: if you have too many of them, you may not be able to open new ones (without additional network hardware, etc.) ...


3

I'm not familiar with the specific site you're integrating with, so this answer is about the general approach to this kind of problem. The best thing to do in this situation is ask the administrators of the site in question how they want you to do it. Of course, this isn't always possible, so if you can't do this, then the following approaches are in rough ...


3

Web Sockets are the better choice The problem with constant polling is that, much like sending small bursts of data (which it pretty much amounts to), your device goes into an 'idle' state that it has to 'wake up' from in between polls. There is a high cost associated with making the initial connection and this cost is repeated for every poll you perform. ...


3

Now that it has been nearly 3 years, and the software in question has been in production with hundreds of thousands of users this entire time, I am going to answer my own question. I went with option 2, where each user joins a single unique room. The server does the work of iterating through the connected users and sending appropriate data to each user (...


3

If i load an asset though the browser normally (http request) will the browser will keep that image in memory once it's no longer being rendered. Browser typically cache files, like images. When asking the server for files it first asks if they have changed. If the browser returns that the file has not changed the browser will use the file from cache. (...


3

I have some cognitive dissonance regarding the pause button - as a user, I consider 'Pause' to mean - halt what the server is doing. From your requirement, though, it seems that the server is not affected by the button at all, which might be confusing, and even misleading, as the feedback to the user really stops. I believe that in most cases, a button ...


3

There are several methods for this: Web Sockets Long Polling (or the blanket term Comet) For solutions, check out: django-socketio Not a django implementation, but a great resource for concepts: SignalR I would recommend going the websockets route, then falling back to long polling. Here's a fairly scholarly article on long polling and best practices.


3

Could using a socket dramatically improve connection time so that the app is much more responsive at initial loading and in case of modifications in previews? Yes. Sockets are designed specifically for this. Could messages exchanged in this socket be asynchronous so that if we ask for 100+ previews at the same time, they will all be loaded very quickly? ...


3

This depends on your architecture. When you deploy a web client and a web server, you cannot guarantee matching versions even if you deploy both at the same instant. Even if there is no caching at all, a user may already have a page open. If it communicates to your server just after you deploy, you'll get that mismatch. So the key here is not to try to ...


3

In addition to the other very good answers here, one way to think about it is that you are not really improving the level of abstraction (in the direction of a full duplex capability) by applying individual wrappers to the input & output streams. While it is true that the input & output streams are individually providing their own single ...


3

I always think of it as: The port is an address on the incoming packet The operating system has been told to put any messages coming into the computer with that port address to a particular place in memory The program knows to look at that memory address to find its messages The bindings are a series of processes in your program telling the operating ...


3

Rooms are a logical grouping construct and have many benefits out of the box for developers using websockets: Rooms make it easier to broadcast to a given set of clients, without referring to individual socket ids of each client. A client can be or not be in a room, while staying connected. Hence rooms provide logical "subscription" to the event topics/...


Only top voted, non community-wiki answers of a minimum length are eligible