this.hubConn = new HubConnectionBuilder()
.withUrl("https://server/hubEndPoint}", {
skipNegotiation: true,
transport: HttpTransportType.WebSockets
})
.withAutomaticReconnect()
When SignalR attempts to start the connection with the server using HttpTransportType.WebSockets, it makes a "GET" call to the server to start it. My middleware intercepts the GET call and I see all the variables of the context (request, headers etc.). However on the reconnect (triggered by withAutomaticReconnect()) SignalR makes another GET call to reconnect to the same URL it was initially built with. So my middleware on the server side intercepts it again. And that is all fine, the issue is that I see NOTHING that is telling me that this second request is made because of reconnection.
Related
My client-server application uses ServerEventsFeature to send commands to the client from the server.
In the client I use ServerEventsClient and its Start method to subscribe to events, but first I'm sending the authentication request to a server using ServerEventsClient.ServiceClient and its Send method.
My client also needs to constantly connect to the server if the connection was broken.
For this I use OnException Action property of my ServerEventsClient, and when the connection breaks, I call the Stop method in the cycle and try again to send the authentication request until the server responds.
It all works well, but if I restart the server, before the client has time to send the authentication request, I see on the server subscribe events (OnConnect, OnSubscribe, and so on), and when checking the properties of a subscription, I get strange values like IsAuthenticated: False, UserId: -2.
Then comes the authentication request, and again there are expected subscribe events, and this time, the property values are already expected like IsAuthenticated: True, UserId: 46.
This SessionId in the first case differs from the value before it is disconnected, but does not match the value after authentication.
In the OnConnect event handler I tried to check the IsAuthenticated property and call the Unsubscribe method of the object IEventSubscription, but after that still occurs OnSubscribe event.
I have 2 questions:
Q1: It is obviously that ServerEventsClient automatically tries to reconnect after a breakup.
In this case, probably the Stop method not triggered because the client cannot perform an unsubscribe request, because the server is not available.
How then to stop this process when unavailable the server?
Q2: Can I prevent an event subscription is not authorized clients?
The Server Events Clients send heartbeats to determine when to automatically try reconnect after it detects a broken connection. You can stop heartbeats by removing the heartbeatUrl returned to the client, e.g:
Plugins.Add(new ServerEventsFeature {
OnConnect = (sub, clientInfo) => clientInfo.Remove("heartbeatUrl")
});
You can limit Server Events to only allow Authenticated Users with:
Plugins.Add(new ServerEventsFeature {
LimitToAuthenticatedUsers = true,
});
I'm using Express with node-amqp. My goal is to create amqpConnection and save it to global object before server starts and in Express routes use previously created globals.amqp_connection.
### server.coffee
app.use( ... )
...
# create RabbitMQ connection before server starts
connection = require("amqp").createConnection
host: "localhost"
connection.on "ready", ->
console.log "Got connection.on(\"ready\") event from node-amqp..."
# make amqp_connection accessible from any point of application
globals.amqp_connection = connection
server = globals.http.createServer(app).listen(8082)
console.log "Express server is listening 8082..."
The problem is connection.on "ready"-event is fired eveytime I call a route. I may suppose that's because of Express way of serving http-requests — executing server.js for every route called. So, for every request, a new instance of connection is created and on it's "ready" app tries to create one more instance of Express server.
How to make amqp_connection accessible from any point of my app, but no doubling require("amqp").createConnection() in every point where I need to push something to RabbitMQ?
UPD: or maybe there is no problem with Express. node-amqp seems to fire ready event every second after creation. Don't know if it's correct behavior
Thank you.
Ready event fired multiple 'cause of connection error:
https://github.com/postwait/node-amqp/issues/255
Sails 0.10.0-rc7
Sails Socket IO : Client not receiving response from server.
Using sails built in blueprints I am attempting to get information from my server using this functionality. (Im looking to use the default behaviour)
Client
//Client on different server (localhost:8000)
//Sails server
var socket = io.connect('http://localhost:1337');
socket.get('/event',function serverSays(err,events){
if (err)
console.log(err)
console.log(JSON.stringify(events));
});
Server
Event Model
module.exports = {
schema : true,
attributes: {
name : {
type : 'STRING',
maxLength: 50,
required: true
}
}
};
In the server terminal (logs) :
verbose: client authorized
verbose: handshake authorized 4TGNw-ywabWYG9j-AHaC
verbose: setting request GET /socket.io/1/websocket/4TGNw-ywabWYG9j-AHaC?__sails_io_sdk_version=0.10.0&__sails_io_sdk_platform=browser&__sails_io_sdk_language=javascript
verbose: set heartbeat interval for client 4TGNw-ywabWYG9j-AHaC
verbose: client authorized for
verbose: websocket writing 1::
verbose: A socket.io client (4TGNw-ywabWYG9j-AHaC) connected successfully!
BUT the callback on my client is never being called????
It seems as if the client connects with the server..
Any suggestions?
EDIT
I must stress that the client and the sails server are running on different servers. The handshake when performing io.connect(localhost:1337) talks with the server correctly based on the server logs.
Its the subsequent action socket.get("/Event") which does not result in anything. Based on the server logs, I would say that its not ever reaching the server....
I thought I would just leave a note as I have my implementation working now.
So as it turns out, I made a fairly embarrassing mistake/assumption.
using Sails js's browser SDK I was connecting to a remote server using:
io.connect("serverurl")
and then happily went about my business attempting to perform various socket functions such as socket.get..
What I did not do is after
io.connect("url")
I still had to ensure that my app had indeed connected to the server by listening on the socket for the connect event:
socket.on("connect",function())...
Once I had this little piece of the puzzle resolved all went and is going swimmingly!
I must also state that I believe the reason I was running into to this issue was because I was attempting to perform the initial connection and subsequent requests in the sails run (init) function. So my subsequent actions were more than likely executing before the app and the server had successfully established a connection.
I believe had the initial connect (io.connect) and the subsequent actions been executed in separate user flows, all would have been as the connection would have surely been established already.
I have a socket.io connection using xhr as its only transport. When I load up the app in the browser (tested in chrome and ff), the socket connects and everything works well until I navigate away from the page. If I reload the browser, I can see the 'disconnect' event get sent out by the client, but the server disconnect event doesn't fire for a very long time (presumably when the client heartbeat times out). This is a problem because I do some cleanup work in the server when the client disconnects. If the client reloads, I get multiple connection events before disconnect is fired. I've tried manually emitting a disconnect message from the client in the window's 'beforeunload' event as well, but to no avail. Any ideas?
I debugged the socket.io server, and I can confirm that Manager.prototype.onClientDisconnect is only getting hit for "close timeout" reasons.
After some more debugging, I noticed the following configuration in the socket.io Manager object:
blacklist : ['disconnect']
That causes this branch from namespace.js to not process the event:
case 'event':
// check if the emitted event is not blacklisted
if (-~manager.get('blacklist').indexOf(packet.name)) {
this.log.debug('ignoring blacklisted event `' + packet.name + '`');
} else {
var params = [packet.name].concat(packet.args);
if (dataAck) {
params.push(ack);
}
socket.$emit.apply(socket, params);
}
The change is detailed in this pull request https://github.com/LearnBoost/socket.io/pull/569. I understand why this is in place for XHR, since anyone could send an HTTP request with random session IDs trying to disconnect other users from the server.
What I plan to do instead is to check each new connection for an existing session id in the server, and make sure to run my disconnect logic before continuing with the connection logic.
Currently, I am implementing an API using nodejs express, then it needs to connect to socket.io and send event.
The API is located in socket.io-client (client), and it connects to socket.io (server)
1st API call: success
The connection is made for the 1st call of the API, message is sent and socket can be disconnected, with the 'disconnect' callback is invoked both on client and server side.
2nd API call: failure
When the API is invoked the 2nd time, the connection to server cannot be made, 'client' callback on client side is not called.
3rd API call: success
Then I tried to restart the client side, keeping other things unchanged. The API is called again, and the connection to socket.io is made successfully and everything is fine.
Can anyone explain the logistics behind this?
Updated
client.js
App.getByUserId(message.to_id, function(error, app) {
var socket = io.connect('http://127.0.0.1:9002');
socket.on('connect', function(){
console.log("client connect socket id:" + socket.id);
console.log("appkey:" + app.private_token);
socket.emit('appkey.check',{appkey: app.private_token, uuid: message.to_id.uuid}, function(data){
socket.emit("forceDisconnect");
socket = null;
});
});
You just hit one of Socket.IO's many "features" or "bugs" depending how you see this. Socket.IO tries to be smart and re-use connections (which causes a lot of connection issues actually) The way around this is use the force new connection option in your io.connect:
io.connect('http://127.0.0.1:9002', { 'force new connection': true });
What you could also do is use https://github.com/primus/primus which wraps Socket.IO if you use the socket.io transformer. Internally, it completely removes the use of the io.connect and uses the much more lower level io.Socket constructor to create more stable connections that you would get with a stock socket.io.
With socket 1.0+, you have to use this for forcing new connection.
io.connect(SERVER_IP, { 'forceNew': true });