I am using a websocket to push data from a process (running in the background) to my electron application (renderer, it's a electron-vue app). Mostly this works great, the data is received and displayed instantly.
In some cases, however, I noticed that the websocket client seemed to buffer incoming messages and only trigger the receive-event after some delay, leading to messages received as a batch.
To verify that the server isn't buffering anything I ran a second connection and simply logged the data (chrome-addon), there all the data is received and processed instantly while my electron application delays the messages.
I am using ReconnectingWebsocket but also tried a plain websocket application:
let webSocket = new WebSocket('ws://0.0.0.0:7700')
webSocket.onopen = function(openEvent) {
console.log('WebSocket OPEN: ' + JSON.stringify(openEvent, null, 4))
}
webSocket.onclose = function(closeEvent) {
console.log('WebSocket CLOSE: ' + JSON.stringify(closeEvent, null, 4))
}
webSocket.onerror = function(errorEvent) {
console.log('WebSocket ERROR: ' + JSON.stringify(errorEvent, null, 4))
}
webSocket.onmessage = function(messageEvent) {
var wsMsg = messageEvent.data
console.log('WebSocket MESSAGE: ' + wsMsg)
}
The WebSocket MESSAGE: is only displayed with some delay. Is there any configuration option, like buffering on the client side or must the render process be called more often..?
Not sure of the solution but we have a demo app using Vue + Electron at https://github.com/firesharkstudios/butterfly-server-dotnet/tree/master/Butterfly.Example.Todo that also uses WebSockets. I've never seen a delay or buffering like you are seeing. Maybe you can compare the implementations to find a cause.
It turns out that it wasn't the websocket implementation but electron blocking the renderer process completely while scrolling, thus the delayed reception. I had to move the websocket connection out of the renderer and tunnel all messages using the IPC system.
Related
I have a ratchet server, that I try to access via Websocket. It is similar to the tutorial: logging when there is a new client or when it receives a message. The Ratchet server reports having successfully established a connection while the Kotlin client does not (the connection event in Kotlin is never fired). I am using the socket-io-java module v.2.0.1. The client shows a timeout after the specified timeout time, gets detached at the server and attaches again after a short while, just as it seems to think, the connection did not properly connect (because of a missing connection response?).
The successful connection confirmation gets reported to the client, if the client is a Websocket-Client in the JS-console of Chrome, but not to my Kotlin app. Even an Android emulator running on the same computer doesn´t get a response (So I think the problem is not wi-fi related).
The connection works fine with JS, completing the full handshake, but with an Android app it only reaches the server, but never the client again.
That´s my server code:
<?php
namespace agroSMS\Websockets;
use Ratchet\ConnectionInterface;
use Ratchet\MessageComponentInterface;
class SocketConnection implements MessageComponentInterface
{
protected \SplObjectStorage $clients;
public function __construct() {
$this->clients = new \SplObjectStorage;
}
function onOpen(ConnectionInterface $conn)
{
$this->clients->attach($conn);
error_log("New client attached");
}
function onClose(ConnectionInterface $conn)
{
$this->clients->detach($conn);
error_log("Client detached");
}
function onError(ConnectionInterface $conn, \Exception $e)
{
echo "An error has occurred: {$e->getMessage()}\n";
$conn->close();
}
function onMessage(ConnectionInterface $from, $msg)
{
error_log("Received message: $msg");
// TODO: Implement onMessage() method.
}
}
And the script that I run in the terminal:
<?php
use Ratchet\Server\IoServer;
use agroSMS\Websockets\SocketConnection;
use Ratchet\WebSocket\WsServer;
use Ratchet\Http\HttpServer;
require dirname(__DIR__) . '/vendor/autoload.php';
$server = IoServer::factory(
new HttpServer(
new WsServer(
new SocketConnection()
)
)
);
$server->run();
What I run in the browser for tests (returns "Connection established" in Chrome, but for some reason not in the Browser "Brave"):
var conn = new WebSocket('ws://<my-ip>:80');
conn.onopen = function(e) {
console.log("Connection established!");
};
conn.onmessage = function(e) {
console.log(e.data);
};
What my Kotlin-code looks like:
try {
val uri = URI.create("ws://<my-ip>:80")
val options = IO.Options.builder()
.setTimeout(60000)
.setTransports(arrayOf(WebSocket.NAME))
.build()
socket = IO.socket(uri, options)
socket.connect()
.on(Socket.EVENT_CONNECT) {
Log.d(TAG, "[INFO] Connection established")
socket.send(jsonObject)
}
.once(Socket.EVENT_CONNECT_ERROR) {
val itString = gson.toJson(it)
Log.d(TAG, itString)
}
}catch(e : Exception) {
Log.e(TAG, e.toString())
}
After a minute the Kotlin code logs a "timeout"-error, detaches from the server, and attaches again.
When I stop the script on the server, it then gives an error: "connection reset, websocket error" (which makes sense, but why doesn´t he get the connection in the first time?)
I also tried to "just" change the protocol to "wss" in the url, in case it might be the problem, even though my server doesn´t even work with SSL, but this just gave me another error:
[{"cause":{"bytesTransferred":0,"detailMessage":"Read timed out","stackTrace":[],"suppressedExceptions":[]},"detailMessage":"websocket error","stackTrace":[],"suppressedExceptions":[]}]
And the connection isn´t even established at the server. So this try has been more like a down-grade.
I went to the github page of socket.io-java-client to find a solution to my problem there and it turned out, the whole problem was, that I misunderstood a very important concept:
That socket.io uses Websockets doesn´t mean it is compatible with Websockets.
So speaking in clear words:
If you use socket.io at client side, you also need to use it at the server side and vice versa. Since socket.io sends a lot of meta data with its packets, a pure Websocket-server will accept their connection establishment, but his acknowledgement coming back will not be accepted by the socket.io client.
You have to go for either full socket.io or full pure Websockets.
"peerConnection new connection state: connected"
{
"janus": "webrtcup",
"session_id": 3414770196795261,
"sender": 4530256184020316
}
{
"janus": "media",
"session_id": 3414770196795261,
"sender": 4530256184020316,
"type": "audio",
"receiving": true
}
... 1 minute passes
"peerConnection new connection state: disconnected"
{
"janus": "timeout",
"session_id": 3414770196795261
}
"peerConnection new connection state: failed"
See pastebin for the full logs.
I'm trying to join a videoroom on my Janus server. All requests seem to succeed, and my device shows a connected WebRTC status for around one minute before the connection is canceled because of a timeout.
The WebRTC connection breaking off seems to match up with the WebSocket connection to Janus' API breaking.
I tried adding a heartbeat WebSocket message every 10 seconds, but that didn't help. I'm
joining the room
receiving my local SDP plus candidates
configuring the room with said SDP
receiving an answer from janus
accepting that answer with my WebRTC peer connection.
Not sure what goes wrong here.
I also tried setting a STUN server inside the Janus config, to no avail. Same issue.
Added the server logs to the pastebin too.
RTFM: Janus' websocket connections require a keepalive every <60s.
An important aspect to point out is related to keep-alive messages for WebSockets Janus channels. A Janus session is kept alive as long as there's no inactivity for 60 seconds: if no messages have been received in that time frame, the session is torn down by the server. A normal activity on a session is usually enough to prevent that; for a more prolonged inactivity with respect to messaging, on plain HTTP the session is usually kept alive through the regular long poll requests, which act as activity as long as the session is concerned. This aid is obviously not possible when using WebSockets, where a single channel is used both for sending requests and receiving events and responses. For this reason, an ad-hoc message for keeping alive a Janus session should to be triggered on a regular basis. Link.
You need to send 'keepalive' message with same 'session_id'to keep the session going. Janus closes session after 60 seconds.
Look for the implementation: https://janus.conf.meetecho.com/docs/rest.html
Or do it my way: i do it every 30 seconds in a runnable handler.
private Handler mHandler;
private Runnable fireKeepAlive = new Runnable() {
#Override
public void run() {
String transactionId = getRandomStringId();
JSONObject request = new JSONObject();
try {
request.put("janus", "keepalive");
request.put("session_id", yourSessionId);
request.put("transaction", transactionId);
} catch (JSONException e) {
e.printStackTrace();
}
myWebSocketConnection.sendTextMessage(request.toString());
mHandler.postDelayed(fireKeepAlive, 30000);
}
};
Then in OnCreate()
mHandler = new Handler();
then call this where WebSocket connection Opens:
mHandler.post(fireKeepAlive);
be sure to remove callback on destroy
mHandler.removeCallbacks(fireKeepAlive);
Here is my paho client code
// Create a client instance
client = new Paho.MQTT.Client('127.0.0.1', 1883, "clientId");
// set callback handlers
client.onConnectionLost = onConnectionLost;
client.onMessageArrived = onMessageArrived;
// connect the client
client.connect({onSuccess:onConnect});
// called when the client connects
function onConnect() {
// Once a connection has been made, make a subscription and send a message.
console.log("onConnect");
client.subscribe("/World");
message = new Paho.MQTT.Message("Hello");
message.destinationName = "/World";
client.send(message);
}
// called when the client loses its connection
function onConnectionLost(responseObject) {
if (responseObject.errorCode !== 0) {
console.log("onConnectionLost:"+responseObject.errorMessage);
}
}
// called when a message arrives
function onMessageArrived(message) {
console.log("onMessageArrived:"+message.payloadString);
}
On Rabbitmq server everything is default seetings. When i run this code i get WebSocket connection to 'ws://127.0.0.1:1883/mqtt' failed: Connection closed before receiving a handshake response
What i am missing ?
From my personal experience with Paho MQTT JavaScript library and RabbitMQ broker on windows, here is a list of things that you need to do to be able to use MQTT from JS from within a browser:
Install rabbitmq_web_mqtt plugin (you may find latest binary here, copy it to "c:\Program Files\RabbitMQ Server\rabbitmq_server-3.6.2\plugins\", and enable from command line using "rabbitmq-plugins enable rabbitmq_web_mqtt".
Of course, MQTT plugin also needs to be enabled on broker
For me, client was not working with version 3.6.1 of RabbitMQ, while it works fine with version 3.6.2 (Windows)
Port to be used for connections is 15675, NOT 1883!
Make sure to specify all 4 parameters when making instance of Paho.MQTT.Client. In case when you omit one, you get websocket connection error which may be quite misleading.
Finally, here is a code snippet which I tested and works perfectly (just makes connection):
client = new Paho.MQTT.Client("localhost", 15675, "/ws", "client-1");
//set callback handlers
client.onConnectionLost = onConnectionLost;
client.onMessageArrived = onMessageArrived;
//connect the client
client.connect({
onSuccess : onConnect
});
//called when the client connects
function onConnect() {
console.log("Connected");
}
//called when the client loses its connection
function onConnectionLost(responseObject) {
if (responseObject.errorCode !== 0) {
console.log("onConnectionLost:" + responseObject.errorMessage);
}
}
//called when a message arrives
function onMessageArrived(message) {
console.log("onMessageArrived:" + message.payloadString);
}
It's not clear in the question but I assume you are running the code above in a web browser.
This will be making a MQTT connection over Websockets (as shown in the error). This is different from a native MQTT over TCP connection.
The default pure MQTT port if 1883, Websocket support is likely to be on a different port.
You will need to configure RabbitMQ to accept MQTT over Websockets as well as pure MQTT, this pull request for RabbitMQ seams to talk about adding this capability. It mentions that this capability was only added in version 3.6.x and that the documentaion is still outstanding (as of 9th Feb 2016)
I want to achieve such a functionality.
That is:
1) in case of connecting to worklight server successfully, Direct Update is available.
2) in case of failing to connect to worklight server, the app can run offline.
Below is my configuration in "initOptions.js".
// # Should application automatically attempt to connect to Worklight Server on application start up
// # The default value is true, we are overriding it to false here.
connectOnStartup : true,
// # The callback function to invoke in case application fails to connect to Worklight Server
onConnectionFailure: function (){
alert("onConnectionFailure");
doDojoReady();
},
// # Worklight server connection timeout
timeout: 10 * 1000,
// # How often heartbeat request will be sent to Worklight Server
heartBeatIntervalInSecs: 20 * 60,
// # Should application produce logs
// # Default value is true
//enableLogger: false,
// # The options of busy indicator used during application start up
busyOptions: {text: "Loading..."
But it doesn't work.
Any idea?
Direct Update happens only when a connection to the server is available. From the way you phrased your question, your problem is that when the app cannot connect to the server it doesn't work "offline". So your question has got nothing to do with Direct Update (if it does, re-phrase your question appropriately).
What you should do, is read the training material for working offline in Worklight.
You are not specifying what "doesn't work". Do you get the alert you've placed in onConnectionFailure? How does your doDojoReady function look like?
I too am using Dojo in Worklight.
My practice is have worklight configured not to connect on startup
var wlInitOptions = {
connectOnStartup : false
in my wl init I then initialise my dojo app,
function wlCommonInit(){
loadDojoLayers();
};
requiring whatever layers I'm using, and then do the actual dojo parsing
require([ "dojo/parser",
"myApp/appController",
"dojo/domReady!"
],
function(parser, appController) {
parser.parse().then (function(){
appController.init();
});
});
Finally, now WL, Dojo, and myApp are all ready I attempt the WL connection, calling this method from my appController.init()
connectWLServer: function() {
// possibly WL.Client.login(realm) here
var options = {
onSuccess: lang.hitch(this, "connectedWLServer"),
onFailure: lang.hitch(this, "connectWLServerFailed"),
};
WL.Client.connect(options);
}
Any Direct Update activities happen at this point. Note that the app as whole keeps going whether or not the connection works, but clearly we can run appropriate code in success and fail cases. Depending upon exactly what authentication is needed an explicit login call may be needed - adapter-based authentication can't happen automatically from inside the connect().
I am working on a .net client application which utilizes SignalR. I want to notify the user if the connection is down for some reason. How can I capture the disconnect event using the native client?
The client will go into the reconnecting when the connection dies.
Therefore you can tie into the Reconnecting event to see when the connection goes down:
var connection = new Connection("http://myEndPointURL");
connection.Reconnecting += () =>
{
Console.WriteLine("The connection has gone down, shifting into reconnecting state");
};
Hope this helps!
I was able to capture StateChanged to detect changes in the connection and notify the user.
connection.StateChanged += (statechange) =>
{
Console.WriteLine("Changing from " + statechange.OldState + " to " + statechange.NewState);
};
This gives me a mechanism to notify the user when the connection is dropped or successfully reconnected.