I'm looking at the Quickblox demo for Video chat, and am interested in perhaps signing up, can someone provide some information on how much resources are needed to run an instance of the Video chat application, per conversation would be fine, may be able to calculate the total for the desired usage. As I understand it the service is a broker for the connection so in theory should be quite small? But would that mean with the Free for instance I would be limited to a single connection being limited to 20 connections per any 20 second period, so if I had a class of 30 I'd need to throttle 10 to have all connect to the chat?
http://quickblox.com/plans/
http://quickblox.com/developers/Sample-webrtc-web
Thanks
Related
I'm using OpenTok Web Client SDK and OpenTok .NET Server SDK to generate TokBox sessions that are always going to be multiparty conferences with video being published by many.
I'd like to limit the number of streams that can be published and somehow set that as a session property. Right now I know this value - the number of current publishers - in the client side, and I can of course prevent a new user to publish, but I'm running into this scenario where two users try to publish at the same time, and both are accepted. Ideally the user who published the very first of the two should be accepted, so I'm wondering if there is a way to set this property in the TokBox "server side", as a session property, so the server would reject a new publisher if max. reached.
Please notice that I don't have any server state on my own that keeps track of the created sessions nor how many publishers they have, etc.
Thanks!
Adam here from the OpenTok team.
There is no server-side setting available in OpenTok to limit the number of streams allowed. You could do something like I suggest in this answer though. Where you keep track of streamCreated Events and look at the creationTime property and if your stream is the n-th then you unpublish. Or you can forceUnpublish the n-th stream.
I want to implement Whatsapp
to send information from an external application. The idea is to use this
external application to send information throughout Whatsapp.
If you can help me about the terms and
conditions and if this query is possible to develop.
There is a way through which you can send WhatsApp message from your self created application. Use this link Chat API.
But it only provides 3 days trail period and after that you have to purchase it.
The process in that is, you have to register with your google account, then scan the QR code provided(which changes after every 45 seconds). and you are set to go, they will provide you the API for : PHP, Node.JS, Jquery, CURL.
One thing more you always have to keep your phone connected with the internet everytime.
Also I found a drawback in that, i.e. they also provide API to read messages, but it is too slow, as in my condition I can see my messages of yesterday but not of today.
With the introduction of topics in android gcm I was evaluating this option to easen the work that should be done to mantain in sync our server with some subscriptions.
However I have read in the documentation that the use of topics is limited to 1 million subscriptions. Does this mean that you can't have more than one million users (with one or more topics) or that you can only have 1 million topics subscribed (for example 100.000 users subscribed to 10 topics each) ?
It's a limit on subscriptions in your app in total, across all topics created within your app.
You will get a TOO_MANY_SUBSCRIBERS error when the number of subscriptions per app exceeds the 1 million limit.
I think the limit has now been scrapped:
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app.
https://developers.google.com/cloud-messaging/topic-messaging
You could try to work around this limit by using multiple SENDER_IDs when registering devices.
Since the 1 million subscriptions limit is enforced application-wide, I'm pretty sure that Google's way of tracking that is via the SENDER_ID.
And then, on the server-side, you'd have to issue multiple publish requests to GCM (each time with a different Server API Key, to support more than 1 million devices).
I'm going to test this theory out and let you know what I find. The worst-case scenario is that it is enforced via the application's package name (com.example.package), and then there is no elegant workaround.
Update: The limit has now been removed!
We’re now happy to announce that we’re allowing unlimited free topics for your app. This means app developers can place an unlimited number of devices within each topic and create an unlimited number of topics.
http://googledevelopers.blogspot.co.il/2015/12/google-cloud-messaging-weve-come-long.html?utm_source=Android+Weekly&utm_campaign=1cb848077c-Android_Weekly_184&utm_medium=email&utm_term=0_4eb677ad19-1cb848077c-337844217
GCM now removed the limit, check this: https://developers.google.com/cloud-messaging/topic-messaging
Also Firebase Cloud Messaging (FCM) the same. https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app. The app server sends messages with payloads up
to 2KB to the topic, and GCM handles the message routing and delivers
the message reliably to the right devices. For example, users of a
weather forecasting app could opt in to a "severe weather alerts"
topic and receive notifications of storms threatening specified areas.
Topic messaging supports unlimited topics and subscriptions for each app.
Check This
[FCM Notifications][1]https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
I'm currently in the early stages of designing a cross-platform mobile app (iOS, Android, WP8). At its core, the application will allow proximity based interaction between an unknown number of client devices.
Could someone recommend a framework or technology that would allow me to push server generated location based proximity alerts to the clients that even scales well? Could push notifications (cross platform using PushSharp) be a viable option for this, or will Push notifications always go hand in hand with some kind of toast notification on the device?
Update: 30 seconds or even a minute delay should do.
Push Notifications have way to much latency to give you anything near real-time. Also Push Notifications are not guaranteed to reach a device.
You really need to think about how much time constrained the location updates should be. You should also make some tests with how fast the GPS on various devices updates. I have tested on a Nexus 4 and it is not near real-time either. So throughout your entire application whether it is server side or client side you will have things blowing your real-time wishes.
However IF you can live with a delay of a couple of seconds to maybe 30 seconds or more, Push Notifications my work well for you, they also scales quite nicely.
EDIT:
Push notifications always go hand in hand with some kind of toast
notification on the device?
There is a concept called RAW notifications, which allow you to send arbitrary information with the Notifications. However personally I would just notify the client about updates ready on a server, where it then can get all the information the application needs. This is because as I said Push Notifications are not guaranteed to ever reach the device, but also because you are limited to how much information you can embed in the Notifications.
So my suggestion for a flow would be:
Client A updates its location and sends it to a web service
Web Service receives info from Client A and prepares notifications for all the other Clients, which need information about Client A and pushes information about they need to update their info.
Client B receives a Push Notification telling it to refresh data from the Web Service and does that.
That would work well if the application is in a background state. When showing in the foreground I would simply poll a server every second or so; Still receiving Notifications just forcing the client to update.
For the "scales well" part, you might also want to take a look at Windows Azure Service Bus Notification Hubs. It's currently in preview and supports only Windows 8 Store apps and iOS but support for Android and Windows Phone is on the way.
Well, I tried to ask this question as a comment on this question, but I thought that maybe no one will notice it, so I decided to ask it as a separate one.
The question is about how to do real-time GPS tracking system things; if we have the following scenario:
Rather than connecting a GPS receiver to a PC, the user will have a mobile device with an integrated GPS receiver.
Location data will be sent over mobile network using GPRS data connection to a server side.
The data will be processed and a KML path file will be created and updated on time intervals and used to track the user using Google Earth.
The question is: what is the best method to accomplish this scenario for the server side; is it a web service, a web application, a windows service, a windows application or what exactly? Taking into account that the system will serve a number of users simultaneously, and that more users may use the system in the future(scalability issues).
Thank you in advance and I highly appreciate any help :)
What kind of device are you using exactly, something like this or something more sophisticated / configurable? If we assume that the device sends its data over TCP, I would consider the following approach with separate input/output processes:
Input: a process listening specific TCP port and storing incoming coordinates to database with a device id. Preferably, your listening loop must be able to handle simultaneous connections without them blocking each other.
Output: web application reading coordinates from database for a given device id and displaying them through the Google Earth API.
Use whatever programming language(s) you are familiar with.
For me there is a technical limitation/risk here -> the mobile device, and its connectivity.
1) What are your requirements? Do you need to support various mobile devices or will you focus on only one platform ?
2) More importantly, you have to understand that GPRS data connections differ from a PC connected to the Internet. There are various connection restrictions imposed by different mobile operators.
If I was to design such a system in order to minimise those risks I would go with a web server running on port 80 which the mobile devices would upload their Long/Lat through POST (or even GET to simplify things).
EDIT: Regarding scalability, it would be very easy to scale things up in the future using tried&tested load-balancing techniques.
EDIT2: Whichever technology you decide to use, i would HIGHLY recommend that the first thing you do is to mock up a prototype. Those connection restrictions could be show-stoppers. Ideally you need to explore them before you have made any serious investment.