User subscribes to a presence channel. Then user's internet connection drops. How do I let the other users know that this user is no longer reachable? How long does it take for Pusher to remove the user from the presence channel when they become unreachable?
Related
I am using websockets to talk with server but I want to prevent client from connecting if a requirement is not met. My code is very simple
let socket = new WebSocket('wss://server.com/server/');
socket.addEventListener('open', function(e) {
// we are now connected
});
How does nodeJS connect? It must send a connect message right? Is there a way to edit that message? I'd like to limit it so connections can not be made unless a key is sent with the connection message.
How it works now I send a "login request message" and if the credentials dont match I terminate the connection but currently people could still open connections without sending the login request. This would be a security issue right? People could just DDOS by creating a bunch of connections without logging in.
It's not NodeJS's responsibility to manage DOS/DDOS requests. That is done at the network layer (routers, switches, load balancers, proxies, etc.). See this answer for more detail: protection agains DOS websocket with ip address
Preventing users from continuing to communicate over the socket can be done after a successful connection is made and then the key sent, after which, if it's marked as valid by the server, it continues, otherwise it closes the connection. The limits on how many times a client can connect (or in this case re-connect) are handled by the network rules.
I am designing a system with Socket.io, Nodejs, Expressjs, Redis, Angularjs in which message delivery is very crucial.
Use Case:
My system needs to listen for notifications on resources which can also be shared among multiple users. Sockets are connected to the server with information about resource so that I can maintain a list of sockets for each resource. When there is a notification for that resource I send notification on every socket for that resource.
ResourceID1 = ["scoketID1", "socketID2"] // Two sockets listening to ResourceID1
I update this list on socket disconnect also by removing that specific socket id out or resourceID list.
This way I make sure notification is sent to every user which is sharing the resource and every session of that user along with every socket which can be multiple tabs for one session. In short "Every Socket".
I am also maintaining a hash for the resource notification so that every time there is a new notification for a resource the particular resource notification hash will be updated.
ResourceID1-notificationHash : { key1:"124", key2: "abc" }
The reason for doing this is that if the socket disconnected like user closed the tab or more importantly user Internet disconnected for some reason. and the server does not receive heart beat socket connection is made again and the last message for that resource is sent to that socket.
To make sure that particular socket(client) always receive the message is my implementation enough?
I know I can implement callbacks for an event but what I did is when a particular tab(socket)that was disconnected, is connected again I send the last message for that resource.
Are there any other network glitches which can cause problems for reliable message delivery?
My implementation is different in a sense that for message delivery I am not considering Users, I am considering sockets which can be multiple for just one user like one user can have multiple sessions at the same time lets say in firefox and chrome and then for each session he can have multiple tabs opened. Reason for choosing sockets is my resources can be shared among multiple users so that for one resource update I may have to send the message to multiple users each having multiple sessions and each session having multiple sockets.
When the socket.io client performs an (automatic) reconnection - as might happen if a mobile client went to sleep then woke up again - does the server get a reconnect event? Or does it just see a disconnection and fresh connection?
In either case is there a way to
identify that it's the same client e.g. by a unique client id that persists across connections
have the client automatically re-join any rooms it was in before
Or do I need to code that functionality manually e.g. by having the client supply the id or rooms itself on reconnection?
I had a read of the socket.io docs and can't see any list of events that the server might receive.
I am using WebRTC to make a audio, video and chat application. How on the server side we can check if the peer is still connected.
Actually, I want to check before making audio/video call that the other user end is still connected. I am able to maintain Presence (i.e online/offline) when user logs in or logs out of the application.
Suppose, the network connection drops or got disconnected, I am not able to get any information on the server side. If I can get, then I can communicate to rest of the peers connected.
So, need help how to get the information if the peer is still connected or not. I am using Nodejs and WebRTC in my application.
Socket.IO has a concept of 'rooms' that makes it very handy for building WebRTC signaling servers, and a disconnect event fired when a user disconnects. You can also set up a custom event to be emited when, for example, a user stops a video stream or leaves a page.
You might want to take a look at the codelab at bitbucket.org/webrtc/codelab, which uses Socket.IO for signaling. (Apologies, once again, for shameless self promotion!)
You would need to implement your own logic to do that.
Since you already have the client registering presence you could:
maintain a persistent connection via websockets
implement a polling/keep alive algorithm between your clients and server
I am working on a Chatting application (needs to connect to a server) on iPhone. The sending packet from iPhone shouldn't be a problem.
But I would like to know whether it is possible for iPhone to establish a incoming socket connection to server continuously or forever under mobile environment.
OR What do I need to do to give the connection alive ? Need to send something over it to keep it alive ?
Thanks.
Not sure why you want to have chatting app to have persisted connection... I'd better use SMS like model. Anyways, Cocoa NSStream is based on NSSocket and allows a lot of functionality. Take a look at it.
Response to the question. Here is in a nutshell, what I would do:
Get an authentication token from the server.
this will also take care of user presence if necessary but now we are talking about the state; once presence is known, the server may send out notifications to clients that are active and have a user on their contact list.
Get user's contact list and contact presence state.
When a message send, handle it according to addressee state, i.e. if online, communicate back to the other user, if offline, queue for later delivery or reject.
Once token expires, reject communication with appropriate error and make the client to request a new token.
Communication from server to client, can be based on pull or push model. In first case, client periodically makes a request and fetches all messages. This may sound not good but in reality, how often users compose and send messages? Several times a minute? That's not too much. So fetching may happen every 5-10 seconds.
For push model, client must be able to listen and accept connections.
Finally, check out SIP, session initiation protocol. No need to use full version of it though. Just basic stuff.
This is very rough and perhaps simplified. I don't know the target complexity of your chatting system. For example, the simplest thing can also be that server just enables client to client communication by distributing their end points and clients take care of everything themselves.
Good luck!
Super out of date response, but maybe it will help the next person.
I would use xmppframework and a jabber server.