I am developing an app where I can send live voice notes. It works just like Whatsapp voice notes, except that the recipient of the voice note can start playing the voice note before the author has finished sending it.
I developed a proof of concept using a webrtc media server. It works like this:
Alice wants to send a voice note to Bob, so she sets up a webrtc connection with the server and starts streaming audio.
The server records the audio as it receives it in file F.
Bob received a notification saying Alice is streaming a voice note (she is still speaking)
Bob opens the app, sets up a webrtc connection with the server, and the server starts streaming the file F in the webrtc connection.
Is there a technology more fit for this type of tasks or should I go along with what I have right now?
Since you're buffering the voice data as a file on the server, you don't really need WebRTC. You can just stream it as regular audio data. WebRTC would be better used if you wanted to stream that audio directly to Bob instead of passing through the server first.
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.
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.
How is the best way to handle messages through a server to multiple devices?
Scenario
It will be an app capable of running on multiple mobile platforms including online in a web browser. A type of instant messenger. The messages will be directed through a server to another mobile device.
The back-end structure/concept must be basically the same as WhatsApp. Sending messages to one-another like that.
What I think
Have the device send it to the web-server.
Server saves it in a queue table in a database.
When receiver device checks for new message (every second) it finds it in the queue.
Remove it from queue and put message in history table.
Final
What would be a efficient way to structure/handle such an app to get similar results as WhatsApp?
You may want to push messages instead of pull them every second. This has two big advantages:
Less bandwidth usage.
You can skip the database part if the sender and the receiver are both connected when the message is sent. Only queue the messages in the database if the receiver isn't connected.
So it's a huge performance boost if you use push.
If you have a web app using JavaScript you can use a JSON stream or, for new browsers, JavaScript WebSokets.
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.
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.