How is it possible to ensure that Autobahn only creates a single connection?
Is it possible to either check for existing connections before calling connection.open, or perhaps kill all other connections on connection.onopen?
When using AutobahnJS (which I assume this relates to), you will generally not need to open multiple connections. If your application connects to a single WAMP server, then you can use the single connection for all WAMP actions while it persists, i.e. for all your subscriptions, publishes, registrations and calls.
Related
I have WebSocket implemented in a real-time application, where connected clients get all server updates without page refresh. That's fine and it's working very well. The problem is as follows:
Lets say I use two servers (server1 and server2) to serve client requests. If a client on server1 updates the database, all clients connected to server1 will get the updates, as expected, because server1 is aware of all connected clients. However, clients connected to server2 do not get any updates because they are being served by server2 who is not aware of the database updates (the updates were done by a client on server1)!
Is there a standard way of handling this? Also assume I have many servers.
If this has been addressed before, I'd also appreciate a pointer to it. Thanks
Handling the DB values, changes should be the responsibility of each instance connected to the DB. Whereas sharing updates (requires DB change or not)across various clients should be the responsibility of the handler. For websocket usually such updates are handles by writing it to a pub/sub channel/queue such as reddis and all instances subscribed to appropriate channel. Whenever any instance wants all clients to receive an update it puts it on that queue and all the instances are able to receive and broadcast it
When we connect to socket.io, we have to define the server IP, or leave it blank if the files are hosted in the same server.
Each emit we fire, will be thrown on each socket connection.
If we have two applications on the same server,
all of the emits from app1 will be emitted in app2 and vice versa.
How to avoid this?
It depends upon what you mean by "two applications". If what you mean is two connections to the same socket.io server, then yes io.emit() is purposely designed to send to all connections to the current server.
If you have two separate socket.io servers on the same host, then those socket.io servers must be on separate ports (you can't have two actual servers on the same port) and when you io.emit() to one it will have nothing to do with the other because the io objects for the two servers will be completely different objects that are attached to completely different servers.
So, it really depends upon how you have things configured on the host. If you show your actual server-side code for your two servers, we could answer much more specifically.
If you just have one socket.io server and you're looking for ways to send a message to a group of connected sockets, you can either use namespaces or rooms. A namespace is something a client connects to. A room is something a server puts a connection into with .join(). You can then .emit() to either a namespace or a room and it will send to all sockets in that collection.
I have TCPListener server based on this source code https://gist.github.com/leandrosilva/656054#file-server-cs
I created a server on port 3340. Whenever a client connects to the server, then server waits for the new client connection. When I connect from my Chrome browser to the server, then it seems there are three clients connected (expected only one).
Why it is like that?
Most clients maintain multiple connections in parallel, including more than one connection per server endpoint.
And RFC7230 section-6.4 explains. Multiple connections are typically used to avoid the "head-of-line blocking" problem
I have to set sails app where I can have socket.io connections on multiple ports - for example authentication on port 3999 and data synchronization on port 4999.
Any way to do so ?
I asked a similar question yesterday and it seems that yours is also similar to mine, here's what I'm going to implement.
Given that you will have multiple instances that are going to work on different ports, they won't be able to talk to each other directly and that breaks websocket functionality.
It seems that there are multiple solutions to this (sticky sessions vs using the pub/sub functionality of Redis), I chose Redis. There's a module for that called socket.io-redis. You also need emitter module, it's here.
If you choose that route, no matter how many servers (multiple servers with multiple instances) OR many instances on a single server you run your app on, it will function without a problem thanks to Redis.
At least that's what I know for now, been searching for a few days, haven't tried it yet.
Not to mention, you can use Nginx for load balancing, like below. (Copied from socket.io docs)
upstream io_nodes {
ip_hash;
server 127.0.0.1:6001;
server 127.0.0.1:6002;
server 127.0.0.1:6003;
server 127.0.0.1:6004;
}
I'm using org.eclipse.jetty.websocketclient and I want to open multiple web sockets to different URLs.
I'm working with Java.
How do I need to do that?
I want to open the web sockets in multiple threads.
1. Do I need to create websocketclient for each connection?
2. Can I use any websocketclient factory? Is there any?
3. Do I need to open only one websocketclient, keep it opened and open somehow web sockets with it?
4. What is wrong with creating multiple websocket clients?
This answer talks about Jetty 9 WebSockets.
you have 1 WebSocketClient, think of it as a Browser, with each call to connect() establishing a new connection.
Each call to connect() should have a new WebSocket instance, each instance will be managed by the WebSocketClient's Executor causing in essence each websocket instance to be on its own thread.
Followup Answers
Ideally, have only 1 WebSocketClient, and start it only once. leave it started for the time period where you have active websocket connections.
Stop the WebSocketClient when there are no more connections.
Generally speaking, avoid reusing objects for multiple requests, unless you know what you are doing. Example: the ClientUpgradeRequest and URI, are associated with the WebSocket Session, which if reused across multiple connections, will have a state change on close of the first connection, making the data invalid for the other connections, then there is also the Garbage collection references that make cleaning up the old connections difficult until all connections are closed.
You can call connect() concurrently, go for it. Each connection attempt is processed based on the Executor behavior (eg: if you have a single threaded Executor, then only 1 connect occurs at a time)
Creating a new WebSocketClient for every connect is excessively wasteful of resources. It would be like starting an entire WebServer for each incoming request. A WebSocketClient manages the selectors, threading, session tracking, etc. I realize where you are coming from, with older http client libraries having this behavior, but even those http clients are updating themselves to this new browser-ish model thanks to spdy and http/2.