Yes, I know it seems like a simple question but I just recently started using PubNub and I am confused on how to disconnect from a channel. I think the command to use is "Unsubscribe" and my misunderstanding relates to the dual use of the word.
Logically, I understand that once you initialize PubNub and publish a message a separate process can subscribe to the establish channel. When it's done it unsubscribes. Got it!
Now we want to completely disconnect from PubNub. That is end the channel.
Do I use the command "Unsubscribe" to do this? I guess I am logically looking for an "End" or "Disconnect" command and not an "Unsubscribe" command because it did not subscribe to the channel, it established the channel. I know it seems petty but until I understand this it's difficult to move forward. So is this a dual use command?
Thanks
You are on the right track here. Depending on the client platform in question, an unsubscribe resulting in an empty channel list will completely disconnect you.
On the more sophisticated clients, advanced/smart frameworks, there are the API calls of un/subscribe (which as you described subs /unsubs you to a specific channel), and separately, the public and/or private method calls defining/detecting being "connected" or "online".
For example, iOS has specific connect and disconnect calls, separate from subscribe/unsubscribe calls. On JS, there is no explicit connect/disconnect, but regardless if you are subbed or not to an active channel list, there may be background "pings/heartbeats" being made to the PN cloud to detect connectivity/online/offline state.
If you give more info on the client platform and version you are on, we can give you more info on how to completely sever all connects to the PN cloud and achieve a "complete disconnect".
geremy
Related
If I have en external process post a message as bot, let's say !help how can make Errbot respond to it? Currently it ignores messages coming from errbot itself. I could not find a configuration option for this.
Good question: It is in the contract of each backend to detect and filter out the messages coming from the bot itself.
This design choice is mainly to avoid weird infinite loop behavior etc.
In general if the bot emits something and needs to react from it, why not doing that at that point instead of waiting for its own response?
Hello i am trying to make a multiplayer game with nodejs and socket.io.
I am using multi process socket.io with cluster and socket.io-redis. It works well if you want to broadcast messages, emit etc.
But if i want to add some complexity in my code problems start to appear. I want my game to have a matchmaking function.
Assume this scenario:
Server find 2 users that want to play and start a game.
Users are on different processes on the same machine.
The problem is that a client can communicate with only one process the one that firstly got in.
So there are 3 possible solutions as I see it:
Matchmake with users that is on the same proccess --- Not good.
Create an ipc method between processes so the one with the target client can broadcast client's answer to the correct process --- Too complex and not sure if solves everything.
Change client's socket.io process to a new one without the user notice it --- Not sure if this is even possible.
Is there something i am missing here? Is there any other solution that i can't think?
Any help appreciated!
With socket.io-redis users can communicate even if they are in different servers/processes, this is why it exists.
I have one or more daemon app running and to communicate with it I have a client app. The client app is something simple executed on the command line. Chances are only one will be up at a given moment. When I do a command such as daemon update-config the client does mq_open and sends the command. Some commands like list I'd want results. It appears that if I run mq_send in my daemon after I receive I may receive the message within the daemon app.
What's the best way to send the reply to the client w/o accidentally processing it in the daemon? After a quick lookup there didn't appear to be an obvious solution so I do sleep(1) which seems to solve my problem completely even though it's a 'hack'. Whats the best solution? is sleep the most understandable and straightforward solution? I don't feel like generating random/unique values, passing it in and opening another mq to send it. The sleep for a second feels like the best solution but I wonder what your solutions may be.
When using messaging systems, you can do RPC calls even if it is not the best paradigm to use messaging in general. The general approach to RPC with messaging is:
have distinct queues for requests and for replies (the latter ones can be ephemeral queues, created for each request, or persistent queues);
give to each message a unique ID, that will be used in the replies to identify which message it was replying to. (it's called correlation_id in AMQP for example).
I do guess that you can use the same approach with Posix queues as well.
I'm attempting to create an application which will work as a chat app. I'm currently contemplating the best way to do this and I'm thinking of going with a server sent event package such as the following. Every conversation would have an id, and the message would be emitted under the id. For instance
stream.emit(1512, "Hello") would send the message and
stream.on(1512, function(message){console.log(message)}) would print the message. Only the chat members would have the chatId.
I was initially thinking of using websockets but I thought that not every user should be receiving data, as chats were private and I didn't want to configure authentication within websockets.
Back to server sent events:
I have a few questions on the topic.
Are they efficient and, if not, what would be a more efficient solution
Is the method of sending chat through a randomized, hashed, id (such as 309ECC489C12D6EB4CC40F50C902F2B4D) secure?
Would you recommend a different method for sending chat? This is to be implemented as a mobile application where individual users can chat privately with oneanother so, again, security is pretty important.
Thanks.
I recommend the client-call package (disclaimer: I wrote it). It provides a very simple method to run a client-side method from the server code.
Besides this, you can always just put the chat messages to a db collection and remove them after some time.
I am using Node.js + ZeroMQ for subscribing to a certain feed using the PUB/SUB pattern.
How could i detect the condition where my publisher is disconnected? (I am connected as a subscriber)
Another thing: is there a way to get automatically messages from the past when i first connected to the publisher?
Thanks in advance
You could publish a heartbeat and if your subscriber misses one or more in-a-row you can assume that you lost the connection and try to reconnect.
To get the messages from the past you need to use a different pattern, like REQuesting those missing messages. In this case you need a way to identify which messages are missing.
In ZeroMQ's default pubsub model, there's no way for the subscriber to get messages from the past. See the ZeroMQ documentation, where you find statements like
If you start the SUB socket (i.e., establish a connection to a PUB
socket) after the PUB socket has started sending out data, you will
lose whatever it published before the connection was made. If this is
a problem, set up your architecture so the SUB socket starts first,
then the PUB socket starts publishing.
and
Pub-sub is like a radio broadcast; you miss everything before you
join, and then how much information you get depends on the quality of
your reception.