I'm writing a p2p chess game that sends 2 byte messages back and forth (e.g. e4 or c4). I'm considering the use of GAE Channel API. I noticed that this API causes the browser to send a heartbeat message to the server with POST URL https://849.talkgadget.google.com/talkgadget/dch/bind?VER=8&clid=...
That fires about every second. I won't be charged for the response data and response headers for those heartbeat requests correct?
Also, when I send data from the server to a browser over a channel, am I charged for only the json string itself or all http header/payload packets?
Google has a newer (and totally free!) API you should look at instead of the channel API (unless its restrictions cant be worked arround.)
GCM (google cloud messaging) is free, with a few restrictions like packet size (2kb in some cases) but it will handle everything for you (queuing, broadcast to all, broadcast to topics, one-to-one messaging, battery-efficient mobile libraries (android and iOS), native chrome support etc.
https://developers.google.com/cloud-messaging/
Make sure to also see this s.o. answer for GCM implementation tips: https://stackoverflow.com/a/31848496/2213940
Related
Google is deprecating Cloud Iot, so not an option.
https://cloud.google.com/iot/docs/release-notes
Cloud IoT Core will be retired on August 16, 2023. After August 15, 2023, the >documentation for IoT Core will no longer be available.
I would like to use Firebase - Firestore for my backend. It takes all the hassles out of keeping a server up and running, scalability etc.
I managed to send data after login and authentication from an ESP32S3 using ESP-IDF in C, (note not Arduino, and not C++), and would like to know if I can rather use a websocket for the communication, once the Authentication done, and if so, can you give me a code example or pointers.
With a websocket, I can send data to my own server hosted in Europe, in less than 400ms.
With Firestore, there is a large HTTP header, that includes the API key, and also the Auth Token, a large amount of data, quite a lot of handshaking going on over HTTPS, and eventually the data is sent. This takes more than 1400ms.
We are weighing items in a farming scenario, and need to weigh very frequently, and the 1400ms with fast internet is not acceptable.
So if I could still go with Firebase Authentication, and Firestore for data, I probably would be able to speed it up to even faster than 400ms if I could use a WebSocket client connection with the Firestore document store. I can use the Refresh Token if needed to refresh the Auth Token, and thus keep the socket connection up, every 3600s as required by Firebase, (that also takes quite long) but less of a hassle, as only once every say 55 minutes.
Any pointers, advice will be appreciated.
Firestore supports multiple SDKs and wire protocols, but none of them work over web sockets. The closest you can get with Firestore would be its REST API, which is documented here. It's not the easiest protocol to work with though, so I recommend using the API explorer that is built into the documentation to create examples for yourself.
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.
We have an application which is experiencing much higher outgoing bandwidth than we would expect given the loads. We have over 10 GB/day of outgoing bandwidth with essentially 0 visitors/day on the front end and a bunch of back end processing (using backend servers and the task queue). We also use memcache.
Google says they bill as follows:
Outgoing Bandwidth (billable)
The amount of data sent by the application in response to requests.
This includes:
data served in response to both secure requests and non-secure requests by application servers, static file servers, or the Blobstore
data sent in email messages
data sent over XMPP or the Channel API
data in outgoing HTTP requests sent by the URL fetch service.
We are not serving static files (it only has a rest api), don't use the blob store, don't send emails, don't use XMPP. We do use the URL fetch service, but only with GET requests. I find it hard to believe that 6000 GET requests would amount to 10 GBs of data.
Does anyone know how I can track down the details of what goes into our outgoing bandwidth usage?
To get an idea of when this bandwidth is being consumed, on the appengine dashboard you can change the charts context to: Traffic (Bytes/Second)
Also, within the dashboard I would open the Quota Details page and give it a quick once over and see if you can isolate which service is consuming the bandwidth.
On a side note, have you reviewed tasks in flight to see if perhaps something is stuck in a queue?
I'm writing a simple XMPP chat application. The interface has been made minimal to accommodate mobile devices. The client uses strophe.js which utilizes a bi-directional persistent connection (BOSH) between the javascript application and XMPP server.
Would this persistent connection consume a lot of bandwidth? I know most mobile phone users have some sort of monthly data quota - I don't want to hog it.
Yes, if you do the math, you need to account for:
HTTP headers sent & received
Possible cookies to/from the server
BOSH typically sends a packet every minute both ways (called the empty body). This takes up considerable bandwidth.
You might want to consider using websockets instead.
http://blog.superfeedr.com/xmpp-over-websockets/
Is there an open source WebSockets (JavaScript) XMPP library?
The XEP (draft): https://datatracker.ietf.org/doc/html/draft-moffitt-xmpp-over-websocket-00
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.