I created a working Google Channel AP and now I would like to send a message to all clients.
I have two servlets. The first creates the channel and tells the clients the userid and token. The second one is called by an http post and should send the message.
To send a message to a client, I use:
channelService.sendMessage(new ChannelMessage(channelUserId, "This is a server message!"));
This sends the message just to one client. How could I send this to all?
Have I to store every Id which I use to create a channel and send the message for every id? How could I pass the Ids to the second servlet?
Using Channel API it is not possible to create one channel and then having many subscribers to it. The server creates a unique channel for individual JavaScript clients, so if you have the same Client ID the messages will be received only by one.
If you want to send the same message to multiple clients, in short, you will have to keep a track of active clients and send the same message to all of them.
If that approach sounds scary and messy, consider using PubNub for your push notification messages, where you can easily create one channel and have many subscribers. To make it run on Google App Engine is not that hard, since they support almost any platform or device.
I know this is an old question, but I just finished an open source project that uses the Channel API to implement a publish/subscribe model, i.e. you can have multiple users subscribe to a single topic, and then all those subscribers will be notified when anyone publishes a message to the topic. It also has some nice features like automatic message persistence if desired, and "return receipts", where a subscriber can be notified whenever OTHER subscribers receive that message. See https://github.com/adevine/gaewebpubsub#gae-web-pubsub. Licensed under Apache 2.0 license.
Related
in my scenario, I want to have some services to be fixed (as in not needing to be updated) and as time goes by adding other services. (I'm using one DB instance, but it shouldn't matter in service broker)
I want to set up the fixed ones in a way to be able to send back a message to the initiator of any message in its queue without me changing its logic and procedures every time I add another service.
is it even possible or do I have to add more logic as new services are created?
If I'm understanding your question correctly, this is how Service Broker works by default. Which is to say that a conversation is between two parties (initiator and target). Once that conversation is established, either party can send messages on it and they will go to the other party. So, if you want to send a message back to the initiator, just send a message on the same conversation handle as the message was received on and you should be good to go.
I have built a web application using JavaScript stack (MongoDB, ExpressJS, AngularJS, NodeJS). The registration works, the authentication works, the chat is which is using Socket.io works but I need a way of distinguishing which client is sending and which client is receiving the message in order to perform further functions with the user's data.
P.S. Since this is a project that I can not publish there are no code snippets in my post, hopefully it is alright
The ultimate design will depend on what you are trying to achieve. Is is "a one-to-one chat" service or maybe a "one to many broadcast". Is the service anonymous? How do you want users find each other? How secure does it need to be?
As a starting point I would assign a unique identifier (UID) to each connection (client). This will allow the server to direct traffic by creating "conversation" pairings or perhaps a list of listeners (subscribers) and writers (publishers).
A connected user could then enter the UID of a second connected user and your service can post messages back and forth using the uid pairing.
conversation(user123,user0987)
user123 send to user0987
user0987 send to user123
or go bulletin board/chat room style:
create a "board" - just a destination that is a list of all text sent
user123 "joins" board "MiscTalk"
user0987 "joins board "MiscTalk"
each sends text to the server, server adds that text to the board and each client polls the board for changes.
Every Socket can send or recieve, your program must track "who" is connected on a socket and direct traffic between them.
I think a fine way to handle the clients is creating a Handler class, a Client object and create a clientList in the handler, this way is easier to distinguish the clients. Some months ago I built a simple open source one-to-one random chat using socket.io, and here are the handler and the client class.
I hope this example can help you.
1.) Create a global server variable and bind connections property to it and whenever the authentication is true ,store socket_id against the id(user_id etc) which you get after decoding your token.
global.server=http.createServer(app);
server.connections={};
If server.connection hasOwnProperty(id) then use socket emit to send your message ,
else store the socket_id against your id and then send your message.
In this way you just need to know the unique token of the target user to send the message.
2.) You can also use the concept of room
If authentication is true use
socket.room=id ; socket.join(id)
when sending message use client.in(id).emit("YOUR-EVENT-NAME",message)
Note: Make your own flow , this is just an overview of what I have implemented in the past.You should consider using Redis for storing socket_ids.
Let's say we have several clients connected to App Engine using Channel API. Each client sends messages, which should be propagated to other conntected clients according to some rules. The tricky part is that clients may not be to the same App Engine instance.
Is there any way to push data from one instance to the others?
(Yes, I know about Memcache, but this would require some kind of polling.)
You're asking two questions here.
a. Can you push data from one instance to another without the use of polling. The answer is generally no.
b. Can one client send messages to the server that can be propagated to other clients? Yes, and this does not require propagating messages to other server-side instances.
Consider the Channel API as a service. Clients are connected to the Channel API service; they are not connected to any particular instance. Therefore any instance can send messages to any client.
You'll need to store the Channel tokens of your clients in the datastore, in some way that's queryable to match your rules.
Your client makes an HTTP request to send a message to your server.
The handler on the server queries for channel tokens that it needs to propagate the message to (either from memcache or datastore).
The handler on the server sends messages to all the clients.
If the list of destination clients is extremely large, you might want to do steps 3/4 in a task queue where the operation can run longer.
It does not matter what instance a client is connected to, that's hidden from you by the API.
Clients can only "reply" to message via standard HTTP commands, they don't actually have any way to respond via the channel API directly.
So Client A on server A1 wants to sent a message to client B on server B1.
Client A posts to a handler. That might be instance A1 or B1. It does not matter which as the server now passes the message on to client B whatever server client B is connected to via the Channel API.
The real point is that no App Engine instance has any data at all, in general. So it does not matter which instance you connect to, it might be the 99th instance or the very first to start up. So you have to design your application so that it's irrelevant what instance is in use.
Client sends message to server via HTTP.
Server sends message to N clients via the channel API.
Channel API does not make a fixed frontend-instance-to-client connection. Any frontend instance can push message to channel if it knows the channel ID.
What you need to do is pass messages cross-channel.
User one sends message normally to server (e.g. via GET)
Server looks up channel ID of second user and pushes the message
Repeat procedure in other direction: second user to first user.
In Google App Engine documentation for Channel API, it is stated that "Only one client at a time can connect to a channel using a given Client ID".
In contradiction, when I try to create a channel with the same Client ID, a new channel is consumed. In other words, when I call creat channel api for ClientID "user_one" channelService.createChannel("user_one"); for ten times, 10 different channels with 10 different token strings would be created, and when I send a message to "user_one" channelService.sendMessage(new ChannelMessage("user_one", message));, all of the ten clients on different devices, would receive the message!
How would you describe this scenario ? How one can benefit from this mechanism (one clientID with different channel, all receiving same message)? how to prevent it from creating multiple channel for single user ?
The documentation is not complete but it describes its intent pretty well. It says:
Only one client at a time can connect to a channel using a given Client ID, so an application cannot use a Client ID for fan-out. In other words, it's not possible to create a central Client ID for connections to multiple clients (For example, you can't create a Client ID for something like a "global-high-scores" channel and use it to broadcast to multiple game clients.)
It's up to you to keep track of the of the number of channels you create for each ClientID. From my experience, what you describe works, but not reliably. The newest channel created with the ClientID works, the older ones, sometimes work, sometimes don't receive messages.
Note that if you're trying this out on the dev_appserver, all the clients receive messages, but on the real server this behavior is not the same.
In the AppEngine Channel API, channels automatically close after 2 hours. We are handling this by rejoining the channel in the onError event.
Is there a chance the messages could get missed if they are sent while the channel is reconnecting?
Our scenario: We have an appointment scheduling system where appointments are booked elsewhere through an API. We use the channel to display new appointments on the schedule as they arrive. But I'm concerned that some appointments could get missed if they are booked during the time when a channel is closed and reconnected. Does the Channel API guard against this?
A little bit of background: the "client id" in the Channel API is used to create a transient XMPP endpoint. A given client id will always map to the same transient endpoint. So when you re-connect using a token to a channel created with the same client id, you are reconnecting to the same endpoint. Because of this you might see behavior where your client gets messages sent before recreating the channel. But there are no guarantees and we don't actively queue messages when they're sent to a channel with no listening clients.
In your case, could you return an up-to-date list of appointments as part of the same response that returns a new token?
You're not 'reconnecting' the channel, you're creating an entirely new one - so yes, messages could be missed. You should get an exception if you try to send a message to a closed channel, however.