I need to build a server and a client that can exchange data in real time with a company's proxy between them. No one has the authorisation to amend the proxy's configuration (in order to allow the WebSocket protocol).
I would need a fallback technology such as long-polling.
Example: client is a user's PC employee. He needs to exchange data with the server, located in the cloud and separated by company's proxy.
Ideally, I would use WebSocket with SSL, but I know some proxies are not configured for WebSocket messages and thus could reject the connection.
The app would therefore switch to another push technology such as long-polling, increasing the chances of getting a successful connection (is 100% guaranteed with proxies? Giving that there are several types of proxies...)
Are there any libraries/frameworks proposing such features?
Usually, secure WebSocket connections do fine through proxies.
In .NET you have SignalR
In node.js you have socket.io
Related
I am creating an application(Nuxtjs) and am having troubles determining a good approach for sending data to the API(expressjs) and retrieving real-time updates. It seems that i can create "bi-di" connections with both protocals [Server Sent Events(SSE) and Axios or Websocket(WS)].
Both technologies work with most of the browsers, so i do not see a need to add additional libraries such as socket.io - For those individuals that do not have a current browser (too bad).
The application is based on user input of form data/clicks. Other users are then notified/updated with the information. At which point, the user can respond and the chain goes on(Basic chat like flow some information will be exchanged quickly while some may not or ever).
In my experience, the user flow would rely more heavily on listening for changes than actually changing the data - hence why i'm considering SSE. Unfortunately, both protocols have their flaws.
Websockets:
Not all components will require a WS to get/post information as such it doesn't make sense to upgrade a basic http connection at the additional server expense. Therefore another method other than WS will be required(Axios/SSR). Example: Checking to see if a user name exists
Security firewalls may prevent WS for operating properly
express-ws makes sockets easy on the API end
I believe you can have more than 6 concurrent connections by one user (which may be pro and con)
Server Sent Events
Seems like the technology is fading in favor of WS
Listening to the events seem to be as easy as listening to events for WS
No need to upgrade the connection but will have to use node-spdy within the expressjs API - This may also be a good implementation for WS due to multiplexing
Little more backend code to setup http2 and emit the SSEs(Ugly code as well - so functions will be made)
Limited to HTTP limitations (6 concurrent connections) which is a problem as the users could easily max this out(ie. having multiple chat windows open)
TLDR
The application will be more "feed" orientated with occasional posting(which can be handled by Axios). However, users will be listening to multiple "feeds" and the HTTP limitations will be a problem. I do not know what the solution would be because SSE seem like the better option as i do not need to continually handshake. If this handshake is truly inconsequential(which from everything i have read isn't the case) than WS is likely a better alternative. Unfortunately, there is soooo much conflicting information regarding the two.
Thoughts?
SSE, Web Sockets, and normal HTTP requests (via AJAX or Fetch API) are all different tools for different jobs.
SSE
Unidirectional, from server to client.
Text-based data only. (Anything else must be serialized, i.e. JSON.)
Simple API, widely compatible, auto-reconnects, has built-in provision for catching up on possibly missed events.
Web Sockets
Bi-directional.
Text or binary data.
Requires you to implement your own meaning for the data sent.
Standard HTTP Requests
Client to Server or Server to Client, but only one direction at a time.
Text or binary data.
Requires extra effort to stream server-to-client response in realtime.
Streaming from client-to-server requires that the entire data be known at the time of the request. (You can't do an event stream, for example.)
How to decide:
Are you streaming event-like data from the server to the client? Use SSE. It's purpose-built for this and is a dead simple way to go.
Are you sending data in only one direction, and you don't need to spontaneously notify clients of something? Use a normal HTTP request.
Do you need to send bidirectional data with a long-term established connection? Use Web Sockets.
From your description, it sounds like either SSE or Web Sockets would be appropriate for your use case. I'd probably lean towards SSE, while sending the random API calls from the client with normal HTTP requests.
I do not know what the solution would be because SSE seem like the better option as i do not need to continually handshake. If this handshake is truly inconsequential(which from everything i have read isn't the case) than WS is likely a better alternative.
Keep in mind that you can simply configure your server with HTTP keep-alive, making this point moot.
I personally avoid using websockets as a 2-way communication between client and server.
I try to use sockets to broadcast data from server to users or a single user(socket), so they can get real-time updates, but for the post requests from client to server I tend to use axios or something similar, because I don't want to pass sensitive data (like access keys etc) from client to server.
My data flow goes something like
User posts data to the server using axios, SSE or whatever
Backend server does what it has to and notifies socket that an event has occured
Socket server then notifies who he has to
My problem with using sockets to send data from client to server is the authentication issue. Technically, you can't pass anything that is not available to client-side javascript through a socket, meaning that to authenticate the action you will have to send sensitive information through a websocket. This is an issue for multiple reasons - if your sensitive data can be accessed using client-side js, there is a bunch of attacks that can be done here. Also someone can listen to the communication between ws and client. This is why I use API calls (axios etc) and store sensitive data to http-only cookies.
So once server wants to notify the user that something has happened, you can easily do that by telling the websocket server to send the data to the user.
You also want to keep your API server stateless, meaning no sockets in your API. I use separate server just for websocket connections, and my API server and websocket server communicate using redis. Pub/sub is a really neat feature for internal server communication and state management.
And to answer your question regarding multiple connections - you can use a single connection between your websocket server and client, and broadcast data using channels. So one channel would be for notification feed, other channel could be for story feed etc.
I hope this makes sense to you. This stack has worked really good for me.
I have just began using socket.io and I have some experience with express. I know socket.io has bidirectional communication while express is only client to server.
This made me think, why don't we just use socket.io with different namespaces and not use express at all?
In which cases should I use socket vs express?
In the case I need bidirectional communication, is it advisable to make the client -> server with express and then use socket for server -> client?
First off express and socket.io are pretty different things. Express is a full-blown web server framework. You use it for setting up a web-site, fielding http requests from a browser, fielding http requests for an API, etc...
socket.io is a communication layer that sits on top of the webSocket protocol and the webSocket protocol uses an http server to establish its initial connection. While there is a little bit of overlap between what you can do with socket.io and Express, they are more different than they overlap.
For example, if you're setting up a web-site, you couldn't do that with socket.io, one would use something like Express.
Now, if you have a specific programmatic need to communicate between an arbitrary client and a server, you have a zillion choices. If the client is in a browser and the programmatic interface is from Javascript in the browser, then you have fewer choices.
From the browser, using http ajax requests via Express is one choice. Setting up a socket.io connection and defining you own messages is another choice.
Reasons to pick socket.io over Ajax calls to Express from browser Javascript:
You need/want two-way communication over the same channel.
The client is sending a lot of requests to the server (the overhead for sending a socket.io message is lower than an ajax call, once the socket is already set up, so if you're sending a lot of messages, then socket.io messages are more efficient than http requests)
Reasons to pick Ajax calls to Express:
HTTP connections are stateless and short-lived which can make implementing high scale, multi-server implementations with failover and redundancy easier.
There are a wealth of tools to use for http connections from authentication libraries to data formats (MIME) to audio to video, etc...
You want your client to run in places where a long-connected socket.io during inactive periods of time may not be practical (perhaps mobile or battery operated devices).
You want to run in situations where there are proxies, firewalls or other network infrastructure that may not support long running webSocket connections or specifically disallow them.
You want a request/response model. HTTP is request/response where you get a specific response for each request and you know exactly which response goes with which request.
So, as you can see, there is no generic answer to this question. It really depends upon the specific of your communication, the interoperability you desire and the exact needs of your code.
Here are some other references on this topic:
Ajax vs Socket.io
Websocket vs REST when sending data to server
Using AJAX vs. socket.io socket messages
websocket vs rest API for real time data?
Problem description
i am working on a Xamarin application that consumes a REST API written in Python flask.
The Xamarin application offers virtual shopping lists where user can collaborate on buying stuff they have on a shared list.
To improve the user experience, i want to be able to actively notify the user about finished items on the list.
Possible solutions:
Synchronous API polling from client side
Notifications are stored by the API in a relational database and have a flag indicating if the user received the notification already.
The API has an endpoint GET /users/:user_id/notifications/ that queries the database for notifications and returns a JSON response with those.
Advantages
fairly simple to implement
Problems
synchronous polling creates a huge amount of http requests
API service remains stateless, making a horizontal scaling with a loadbalancer easier
Websocket endpoint on the API
The API has an endpoint POST /users/:user_id/notifications/register which creates a websocket connection between client and API.
The connection is stored to a global array in which each entry maps a client id to a websocket connection.
When a new notification is created, the endpoint makes a lookup in the connection dictionary by comparing the owner id of the notification with the dictionary entries. The notification is sent to appropriate user through the websocket.
Notifications are stored in the database like in the first approach.
When a user calls the endpoint, a new websocket connection will be established first and upon success the API sends all unseen notifications from the database to the user.
Advantages
API can push notifications to clients asynchronously
Problems
When a user terminates the websocket connection his dictionary entry will persis
Retaining one websocket connection per user permanently adds additional overhead to the API
Horizontal scalability of the API is more difficult because the service is not stateless anymore (Websocket connection information saved in
RabbitMQ
The API uses a RabbitMQ service to send notifications to the client. Every client uses subscribes to his own notification queue to prevent the broadcasting of messages.
Advantages
API remains stateless
Problems
Notifications needs to be resend to the exchange when a user is offline
Amount of queues grows drastically
Additional costs for RabbitMQ service
High temporary load on the RabbitMQ service when many users come online in the same time
Final words
It would be interesting to hear the opinion of others.
I believe the active distribution of notifications from backen services to clients i a very common use case.
best,
D
I would use RabbitMQ and consume events forwarding them as push notifications. This will work while the user is not actively connected to the website and enhance the engagement with each user experience that will return to the website when notified for more information see How to setup basic web push notification functionality using a Flask backend or How to send push notifications to a browser in ASP.NET Core or Sending Notifications with Spring Boot, Angular, and Firebase Cloud Messaging this way the RabbitMQ will not wait until the user is back online. If the user is online you can forward the notification directly to the Xamarin application via WebSockets and a load balancer like NGINX that can handle many WebSockets in an optimized way.
Synchronous API polling from the client-side is the less preferred way since it overloads the webserver with requests while nothing was changed.
I don't think the scalability of WebSocket is a problem. You can scale up easily with pub/sub. The hotspot of long connections is a kind of serious problem.
For one-way communication, I would suggest Server sent event. In the end, it usually depends on what your team is confident with.
I can recommend on a different approach for API that provides JSON which is called GraphQL
It supports subscriptions capabilities that are pushed by the GraphQL API Server (using web sockets)
GraphQL is considered today to be better than RESTful API since its very flexible and you can get exactly the data you need with one query.
I'm currently building a game that uses a client/server model. I'd like the server side to be a WCF service. The client will be silverlight or flash. What need to solve is session authentication. A user needs to log into the game, be authenticated via the service and hopefully establish a "session." I need to make sure that you can't send commands to the server without being authenticated. Authentication on the server side will be tied to a SQL database. I should also mention that it needs to be a duplex connection.
Related to this question, what about load balancing? If the service runs on multiple machines and is load balanced with the NLB service and I store those connection references, how would I get a reference to a client connected to a different machine in the same cluster?
If SSL is handled by a load balancer, do I still need to configure it in the WCF serviceCertificate node? My scenario is to use message level security. If someone can explain how load balancing with wcf and ssl works, that would be very nice.
WCF requires security tokens to be passed over a secure transport if the message itself is not signed/encrypted. Since traffic is HTTP between your Big-IP and your individual web servers, you need a way to have security tokens that you know are secured between the client and the Big-IP up front still be passed to your server farm. There's a couple ways to do that depending on what version of WCF you're using:
If you're using WCF 4.0 you can just create a custom binding and set the AllowInsecureTransport property on the built in SecurityBindingElement to signify that you don't care that the transport isn't secure.
If you're using WCF 3.5 you have to "lie" about security with a custom TransportSecurityBindingElement on the server side. You can read my old post about this here.
FWIW, they created a hotfix release for 3.5 SP1 that adds the AllowInsecureTransport to that version, but I don't know if your company will allow you to install custom hotfixes.
If you want to use message security then each message is encrypted and signed separately - there is no secure connection and load balancer behaves as with any other HTTP transport. Loadbalancer doesn't know about security and doesn't need certificate.
There are two gotchas:
All load balanced application servers hosting your WCF service must use the same certificate
You must ensure that your WCF binding doesn't use sessions (reliable, security) otherwise you will need load balancing algorithm with sticky sessions (all request for single session always routed to the same server)
It doesn't. Don't bother with this. You will be in a world of hurt. Just install the certs on each machine. We've recently been through this fiasco. WCF is not worth the effort it thinks it needs SSL but sees that it doesn't have it. Take a look at openrasta or something else if you want to do all your SSL on the loadbalancer. #microsoftfail