Im need to verify callback, what would twitch start send events. How to does process goes?
Im already subscribe to event, left only verify my callback
Related
I would like a command that sends a message on a channel, whenever my bot is added or removed from a server!
The Client event, guildCreate and guildDelete is emitted whenever the bot joins and leaves the guild respectively which requires Guild object as a param. Inside those event, you can get the specific channel that you want to send the message to.
Eg:
Client.on('guildCreate',guild=>{
client.channels.cache.get("channel_id").send(`Joined the server ${guild.name}`);
});
Client.on('guildDelete',guild=>{
client.channels.cache.get("channel_id").send(`Left the server ${guild.name}`);
})
Using ws package from npm you can do something like that:
const ws = new WebSocket('ws://localhost:9003');
ws.on('open', () => ws.send('rcon_password PASSWORD'));
ws.on('message', result => console.log(result));
If server expects client to send password then returns authentication result, how can i check result sent by server?
In Python you could do something like:
async with websockets.connect('ws://localhost:9003') as websocket:
await websocket.send('rcon_password PASSWORD')
result = await websocket.recv()
Client can send other commands later. How to relate data sent with ws.send() with those sent to another function in the event onmessage?
The webSocket protocol itself has no concept of a response to a message you send. And, because Javascript is event driven, you can't just block waiting for the response). So, the server just needs to send a message back to the client and the client needs to have a handler for incoming messages and handle the response appropriately when it arrives. If you need to make sure it's a response to THE specific message you previously sent to the server, then you can include some sort of messageID (that you coin yourself) when you send the first message and include that same messageID in the server response.
If you step up to the socket.io library for both client and server (which runs on top of the webSocket transport), then it has built-into it the concept of a response to your message. When sending your message, you just register a callback that gets called when the response comes back and the server has to handle its side appropriately to trigger the response callback on the client.
I got a post function to add new user. I dont see any need to return anything to the client. Will the node thread stuck until he find a respond to send back? Is this a good approach?
(I use express)
app.post('/newUser',function(req,res){
users.push(req.body.user);
});
You should always return something to the client. The client waits for a response.
In the case of adding a user, you could return the created user or, if it fails, an error message.
I am writing a node.js application to make a call or send sms to users.
However, after making a call or sending SMS, I wish to know its status.
client.makeCall({
to:'+358xxxxxxxxx',
from: '+15005550006',
url: "https://demo.twilio.com/welcome/voice/",
}, function(err, responseData) {
}
I know on responseData, but its status indicates 'Queued'
I wish to know the real call status after the actual call takes place.
Is there anyway to do so?
I haven't used twilio node.js client, but here's some that might help you -
You are not getting the call status because the voice call or SMS wont complete immediately when the API call is returned. You need to make subsequent requests again until the status is complete (polling) or configure twilio/pass parameters so that twilio will notify you when the call is actually complete (push).
To let twilio push the status to your server, pass application_sid or status_callback field while making the call request as explained in the API doc http://www.twilio.com/docs/api/rest/making-calls.
To manually request the call status, do the get request from the client after few seconds (or whatever time you think call takes to complete) perhaps using a timer until you get the status you want. http://www.twilio.com/docs/api/rest/call
Something like below: (Note: I have not tested or verified this)
client.calls(<sid>).get(function(err, call) {
console.log(call.status);
});
From node-redis documentation on github:
NOTE: Your call to client.auth() should not be inside the ready
handler. If you are doing this wrong, client will emit an error that
looks something like this Error: Ready check failed: ERR operation not
permitted
So does that mean that when client.auth executes a callback passed to it, it is safe to assume that this connection is ready for normal commands as well? If no then is one supposed to juggle two callback functions, determining which one was called second?
When no auth is required, node-redis sends INFO to the server to detect when it's ready and then fires the ready event (see https://github.com/mranney/node_redis).
When auth is required, it looks like redis will only start accepting commands once the auth is complete (see http://redis.io/commands/auth).
So what I would do is respond to the "ready" event when not authenticating and respond to the auth callback when authenticating (probably having used {no_ready_check: true} when creating the client).