Greetings gents,
EDIT: forgot the link to the sample, here it is: http://code.google.com/p/java-channel-tic-tac-toe/source/browse/trunk/src/com/google/appengine/demos/channeltactoe/
So i'm studying the channel API of AppEngine and i stumbled onto a question regarding the way it's architecturally coded. They way i perceive it works is the clients send standard POST requests, the game gets updated and the both players get the update through the ChannelService a JSON message.
Now i read on the javadoc that Channel is a two-way communication channel, so why did this developer go for the POST servlets(for game-updates) and Channel for distribution instead of using a single servlet for the sole creation of the Channel and then using that channel for front and back game updates communication between the client and server?
To summerize, what did does this architecture gain over using a true 2-way channel, or is it even possible to use the 2-way(back to server channel) in that way.
Thank you for reading, i hope my question is valid/understandable.
-Rohan
I don't know where you read that Channels are bi-directional; they're not. Channels are solely for sending messages from the server to the client. Client communications have to utilize standard HTTP requests.
Related
I would make a chat app where server communication is allowed only for signaling.
I checked this video: https://www.youtube.com/watch?v=WmR9IMUD_CY
This video goes about "real time" communication, for me some delay is ok. I would make chat application which only send text, but not video content. The question raised for me:
How to generate ice candidates to get list ip addresses / ports? How to make request to stun server?
If we have the ip and port list shared through the signaling server on both side, then how one client call the other client and send or receive text? Can I use axios for sending, and set one of the ip - port pair from the list as url? How to receive message?
Maybe I do not even need webrtc as the data transmission does not need to be realtime, some delay is ok?
Would you show a basic demo?
Maybe that is what you are looking for Google Code Lab Friendly Chat
but if you want to learn more about WebRTc I really recommend this article so you will can see if is that what you want.
I am implementing google smart home actions for my device. The device is a camera with the action.devices.traits.CameraStream. I want to know what is the best way to respond to the action.devices.commands.GetCameraStream command asynchronously.
Currently, once my server receives this command, it needs to notify the device and wait for the device to start streaming. Then the server can respond to google with the cameraStreamAccessUrl. This is not ideal because the server is being blocked and exactly how it knows the device has started streaming is a bit tricky. I am wondering if there is a better way to achieve this, for example, the server can respond immediately with some sort of deferred response and have the device tell google what the cameraStreamAccessUrl is.
Is this possible? Thanks for your help!
It sounds like you're trying to find something like follow-up responses to asynchronously notify the stream has started. Unfortunately, CameraStream does not currently support follow-up responses, but you could file a feature request on the public tracker.
I guess that the Title is quite explicit, but I will try to further explain my requirements so maybe anybody can help.
As explained Im building a site that uses DRF as backend and React in the client side, and i would like to have some real time functionalities, so I´ve been researching on the issue which took me to Channels as the way to manage asyncronous actions and websockets. The question is that the more I read the more I get confused... by the Channels documentation one might say that it has capabilities to work whether sincronous as asyncronous server..but then i do not want to miss my DRF classes that simplify my life so much... and the there is this other question coming to my mind regarding if then, i must also use socket.io in the front to connect with channels on the back.... so as you see... im quite confused...anybody could help?
I'm not sure about the client-side and socketio. but yes you can use Django channels and react to communicate on a WebSocket. you also be able to send a message on channels outside of consumers(API view). but it's kind of risky to retrieve data from WebSocket outside of the consumer. everything in consumers(channels) execute asynchronously so accessing received a message on WebSocket by API is not guaranteed.
1 - set up a Django-channels consumer and on connect add the channel to a group
2 - connect to the channel by react and communicate with the server and keep the channel open.
3- make APIs for events and send the event from API to the channel group.
Hi I am currently using channel API for my project. My client is a signage player which receives data from app engine server only when user changes a media content. Appengine sends data to client only ones or twice a day. Do you think channel api is a over kill for this? what are some other alternatives?
Overall, I'd think not. How many clients will be connected?
Per https://cloud.google.com/appengine/docs/quotas?hl=en#Channel the free quota is 200 channel-hours/day, so if you have no more than 8 clients connected you'll be within the free quota -- no "overkill".
Even beyond that, per https://cloud.google.com/appengine/pricing , there's "no additional charge" beyond the computational resources keeping the channel open entails -- I don't have exact numbers but I don't think those resources would be "overkill" compared with alternatives such as reasonably frequent polling by the clients.
According to the Channel API documentation (https://cloud.google.com/appengine/features/#channel), "The Channel API creates a persistent connection between an application and its users, allowing the application to send real time messages without the use of polling.". IMHO, yours might not the best use case for it.
You may want to take a look into the TaskQueue API (https://cloud.google.com/appengine/features/#taskqueue) as an alternative of sending data from AppEngine to the client.
Every example for GAE Chats uses some kind of polling. However, if my GAE app holds a list of clients (in the datastore if necessary), perhaps I could avoid polling by sending a message to all these clients. How can I achieve this?
If you are talking about HTTP, the short answer is that GAE does not currently support it. What I think you are asking about is sometimes called BOSH. Once WebSockets become more widespread, they will be an excellent solution for this problem.
In the mean time you might want to look at XMPP. Using XMPP you can avoid polling. Google has announced a Channel API (yet to be released) which will basically give you the same features as websockets.
You've probably seen some chat room examples...
Since you just want to send a message to users on your datastore (Tip: the IMProperty is great to store such data), it's just a matter of directly sending the message:
from google.appengine.api import xmpp
# `destination` is a list of JIDS
# `message` is a normal unicode string
xmpp.send_message(destination, message)
You can find a great tutorial on using XMPP by Nick Johnson here
Note that you can now use the App Engine Channel API for this: http://code.google.com/appengine/docs/python/channel/
You can create a channel for a given client using:
channel.create_channel(client_id)
Then when you want to update that client, send a message:
channel.send_message(client_id, message)
Basically each client will get a persistent connection that you can push messages over.