58

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 ...


16

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 ...


15

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. ...


6

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 ...


6

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 ...


6

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.) ...


6

If you have 1 server doing everything, there's really no reason to use Kafka at all. If you distribute, which you probably have to if you want to scale to millions of users, other aspects come in. Clients who speak may not speak to the node where the recipient is. In this case, you'll have to route messages and/or do a database polling on each node to look ...


5

Masking is useless with wss:// aka WebSockets over SSL/TLS. Since it is recommended to use SSL/TLS whenever possible, you can reasonable conclude that masking covers a marginal use case.


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

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 (...


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

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

People think of kafka as a message broker, but it's also sort of a database that stores and retrieves messages in order, and tracks every consumer's place in that list. This is an extremely nice fit to store something like chat messages, especially if the websocket box on your diagram is actually multiple websockets on multiple machines, where the bottom ...


5

You only need websockets if you want the communication to be initiated by the server, not the client. Unless I misunderstand, in your case, the client seems to initiate every communication. In that case, Ajax is sufficient and I would advise to stick with what you already know. You would need websockets if the underlying dataset updates (while the client isn'...


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 write ...


4

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. ...


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

Generally, you want your webservice to receive and respond json messages. This is to allow maximum flexibility for later. The addition of new fields doesn't change the underlying types expected on one end or the other. Expanding on this further, generally you always want the root to be an object, and not an array. This is because arrays can be empty, and ...


4

There is no one answer to this, because over the years there have been many, many different chat programs and protocols, but there are a few basic ways of building it: Store and forward, with polling. This is the most basic setup: Alice sends a message addressed to Bob to a central server, which stores it in Bob's inbox; Bob's client periodically "...


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

It's all about discovery: the ability of your API to be understandable and usable by the next developer encountering it. If the WebSocket methods are easily discoverable, and it is clear that they should be used in conjunction with the ordinary REST methods, then your design is probably sound. In practice, for this discovery to occur, I think your ...


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 ...


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