Hot answers tagged

19

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


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


4

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


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

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


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

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


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

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


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


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


2

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


2

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


2

'GUI' or web fronted You can choose between several very easy and fancy web frameworks to build the frontend (you already mentioned web.py and Cherrypy). Personally I prefer Flask, which is actively maintained, widely used, easy to learn, very lightweight and has great docs/community. 'Backend' or asynchronous tasks Celery is a good library to have tasks ...


2

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


2

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


2

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


2

I suppose that since my users will navigate between pages, the websocket handshake will have to be remade after each request, which might be bad because of the additional overhead (not so sure though..). Bad in what sense? Yes, there will be additional load on your server, but it probably won't be a big deal. Your main goal at this stage should be to ...


2

You could use all 3. Use the REST API for posting information to the server, websockets for immediate updates, and fall back to push notifications to the end user if the app isn't running (and the user wasn't notified over the websocket connection). Of course, the REST API isn't strictly needed since you can perform the same server-side actions using ...


1

Ideally you should be pushing to your websocket (through a http request or any queue mechanism as mentioned in the other answers) server at the time the writes happen to the database. That way you can completely avoid polling the database. If you have no other go but to use the database, then execute one query which will get the information for all the ...


1

The push event can simply be a notification that stuff have changed on the server. It does not have to contain the actual data. The clients can pull that data only if and when they need it. This way, you will not have any additional overhead on the server. On the contrary, you get rid of the polling requests every 5 seconds. The only disadvantage of ...


1

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


1

This can be done using a WCF CallBack contract. If the client can make a connection to the server, the server can use a WCF service with a callback construction. This describes that the server expects the client to implement a service as well (the callback service), as part of the service contract. This beaks down as follows: The server hosts a WCF ...


1

You could use NodeJS and the node package module Socket.io for this. Separating the tasks of client connections and creating/returning dynamic web pages into node modules could work the way you described. Node describes their modules in their API docs. The book NodeJS in Action has some projects that perform similar functionality (even the basic ChatApp in ...


1

What you suggest is the usual way to achieve this - the alternative is to directly communicate with the other devices in a per-to-peer topology, but that breaks down quickly as devices are added. So your requirement is to check and detect errors. You could implement a heartbeat to the server so you know its alive, and/or you can add a version number that ...


1

That is how HornetQ's websocket implementation works (Stomp doesn't necessarily have to work over WebSockets but HornetQ exposes both naked TCP and WebSocket options). StompConnection.java Essentially the connection object is wrapped with the metadata of the HornetQ session ID and the login credentials and flagged "isValid". So yes, it's certainly a ...


1

There are a few ways you could solve this problem.I understand from your diagram and question your one of your client say client 1 is the server and your server is actually a proxy to redirect connections.The following solutions are in order of their complexity. First is a networking solution: If connectivity between client 1 and client 2 is all you need to ...



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