I am new in webrtc.I need to create a new implementation of webRtc. I got the source code of apprtc from Github. it is working fine on my local machine.
But in apprtc, it will support only maximum 2 clients(only one client can join to a single room). I need to modify the apprtc to support more than 2 clients. I want to join multiple clients to a single room. Is it possible with apprtc? if else, is any other way using webrtc?
Try https://httprelay.io it allows one to many communication via ajax requests and requires no additional libraries.
Related
I'm currently building a dotnet core project that receives data from multiple devices and has to send them over to Cumulocity.
So the flow of the app would be something similar to:
dotnet core app receives new data
connects to cumulocity account
creates device with name according to data received
sends data
repeat for multiple devices
I've been doing this for the past week using this code.
It works fine but then i noticed that calling the client.CreateDevice(...) was not creating new ones when presented with different data, it always hit the same one.
This tells me that i'm probably doing this wrong, that this library is to be used only within devices and not this way.
So my question is, to handle/send multiple devices data to the platform which library should i be using (if any)?
Thank you.
I figured it out, when connecting to Cumulocity the ClientId value will identify the device, to create new ones i just map that property to my devices ID.
Problem solved.
I am trying to query public utility data from an API (oasis.caiso.com) with a threaded script in R. Apparently this API will refuse requests from certain IP addresses if too many are made. Therefor I need to run many different API requests in parallel across different IP addresses, and am wondering if a machine with many different CPUs on google cloud platform will allow this?
I was looking at the n1-highcpu-96 option from this page: https://cloud.google.com/compute/docs/machine-types
If this is a poor solution can anyone suggest another distributed computing solution that can scale to allow dozens or even hundreds of API queries simultaneously from different IPs?
If I needed multiple IP to perform "light" API calls I would not scale vertically (with a machine having 96 core). I would create an instance group with 50 or 100 or n Debian micro or small preentible instances with the size depending on the kind of computation you need to perform.
You can set up a startup script loaded in the metadata or in a custom image that connects to the API server do what it has to do and save the result on a bucket and if the instance get a "API refuse" I would simply kill the instance automatically having the instances group creating a new one for me with possibly a new IP.
This I think is a possible easy solution to achieve what you want, but I guess there are multiple solutions.
I am not sure what you are trying to achieve and I think you need to check first that it is legal and if the owner of the API agree.
I'm trying to create a virtual classroom. Since I'm not familiar with the web conferencing (or conferencing) terminology, I'm not sure if I'm understanding WebRTC's capabilities as I should.
I've looked in the examples for WebRTC, and all that I've found seem to be peer-to-peer connections. As I understand it, peer-to-peer connections are between two entities. However, virtual classrooms are different as far as I know; they require all parties to be connected to each other, so that when one user speaks/types, all users hear her.
Is such a thing possible with WebRTC? If so, what is it called and how can I read more about it?
Check out the open source Big Blue Button project (http://bigbluebutton.org/). They're currently Flash based but are actively moving towards webRTC. Rumor has it they'll be using Kurento as their MCU. They also have open source mobile (Android/iOS) application code.
According to http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/, such a thing is possible:
Beyond one-to-one: multi-party WebRTC
You may also want to take a look at Justin Uberti's proposed IETF standard for
a REST API for access to TURN Services.
It's easy to imagine use cases for media streaming that go beyond a simple
one-to-one call: for example, video conferencing between a group of colleagues,
or a public event with one speaker and hundreds (or millions) of viewers.
A WebRTC app can use multiple RTCPeerConnections so to that every endpoint
connects to every other endpoint in a mesh configuration. This is the approach
taken by apps such as talky.io, and works remarkably well for a small handful
of peers. Beyond that, processing and bandwidth consumption becomes excessive,
especially for mobile clients.
Maybe you can try searching in the webrtc google group
hope this helps
The question is more targeted at server side development.
When writing a REST API, I want to write it in such a way that it can be consumed by both desktop and mobile applications.
Could see two possible approaches:
Each API should support pagination and the responsibility should be delegated to the client of how much data should be fetched in one go. So , mobile apps will ask for fewer pages in one go and desktop applications will ask for more.
Separate APIs for mobile devices hosted separately. The front-end web server can check the user agent (i.e. source from where is request is coming) and if it's a mobile device, then re-route the request to the server hosting the APIs for mobile devices.
Interested to know more strategies around this.
Appreciate your inputs.
I would suggest a bit of both (1) and (2), here's how.
Instead of re-building whole new api for mobile itself, Have adapters for all the supported devices. i.e have a layer on top of you REST API implementation which renders/instructs the underlying service to return the content suitable for selected mobile device.
coming to pagination, you can parameterize the pagination as an input from the Abstraction mentioned above.
I would recommend something closer to option (1). If the main difference between the clients will be the amount of data they request at a time, it seems trivial to add some kind of query parameter or HTTP header to the REST API indicating how many records to return, for instance.
Relying on checking the User-Agent header may require you to maintain a list of known client user agents and match against them, which would be an additional maintenance cost of a separate API.
I am not a professional developer but I want to develop one project that includes sending message through mobile connected through USB port only... And if possible I want to keep it generalized, like no need for handset model and service provider name.
I don't think it's possible to do this. Certainly at the very least it would depend on the model of mobile in use.
However as an alternative approach there are companies that provide a (paid for, but not expensive) SMS service accessible via a web API. This may suit what you are trying to achieve.
I don't think you will find this easy. Messages can be sent in 2 different modes 'text' or PDU. Support for both modes is not universal across all phones. PDU is the most widely available type on modern phones, but is also the most complex. Not all mobile phones expose a modem to the computer eg. Windows mobile 6.*. Many phones use proprietory software that does not support all commands. Different phones will connect to different COM ports so this will need checking every time, and could prove tricky if there is more than one phone/modem connected. However using just one phone and sending messages in text format after configuring the settings manually the first time is very easy.
See an example here http://www.codeproject.com/Articles/34360/vb-net-AT-commands-to-send-SMS