Hi i building interactive live streaming app.
When i wish to leave channel i want to stop all hosts broadcasting to audience
also.Is there any api for that?
I used "leaveChannel" and "mute" apis but doesn't resolve my problem.
There are two ways to do this.
When the user leaves the channel, he can send a signal to the channel members through Agora RTM sdk. When the broadcasters receive this signal, they can call unpublish or mute to stop sending streams. Or they can call setClientRole to switch their role from broadcaster to audience.
RTM sdk quick start: https://docs.agora.io/en/Real-time-Messaging/messaging_android?platform=Android
When the user leaves the channel, he can call the "kicking-rule" RestFul API to specify who can send streams in the channel.
Kicking-rule API: https://docs.agora.io/en/rtc/restfulapi
Related
I have a WinForms application and I want to receive inbound SMS using Twilio. I am using VB.NET. The code that I find on the Twilio website are using web application and MVC. Can anyone help me how to use it in WinForms?
Did not get enough to try out anything.
Twilio uses a standard way of notifying your service, called webhooks. When an SMS, phone call, or something else happens, and you configure a webhook for that, Twilio will send HTTP requests to the URL configured as a webhook.
This does mean that you have to have a publicly running web server that can accept those HTTP requests with the details of the SMS, phone call, etc. That's why the samples will use ASP.NET, as this is only possible with web technology.
Winforms runs on your computer and doesn't expose any public web endpoints to receive the webhook HTTP requests, so you can't receive it directly. However, depending on your use-case, you have options.
If you don't need real-time updates, you can read the message history using the Twilio C# .NET SDK.
In your winforms app, you could add a button to refresh the messages on click. Alternatively, you could query the message X amount of seconds to give it a more real-time feel, even tho it's not really real-time.
Warning: to use the Twilio API to get the messages, you'll need to embed the Twilio credentials into your Winform app. Anyone that has access to your app will be able to read those credentials. Keep that security risk in mind!
The second option is to use ASP.NET to receive the webhook HTTP requests, and then use a SignalR or websockets to notify any connected clients, of which your winform app would be one.
For example, when Twilio receives an SMS, the ASP.NET application receives the webhook HTTP request, the ASP.NET app then send the SMS details to all clients connected to your SignalR hub, and then your Winforms app receives the SMS payload which you can use to render your app.
The second option is a lot more work and requires more infrastructure since the ASP.NET app needs to be hosted somewhere. We don't have a tutorial for that, but I'd be happy to forward more links to docs etc. if you have questions.
I would like to use Agora Signalling SDK to create a chat app.
I am aware that I can use the onMessageChannelReceive and onMessageInstantReceive callbacks to receive messages that were sent.
Is it possible to get messages that were sent previously? If a user logouts and logs in back, is there a way to get the messages that were sent previously?
Currently the Agora Signaling SDK does not support persistent messages. There is a new Realtime Messaging SDK that is in beta that will have more robust features. I would recommend you reach out to the Agora.io team to get more information because I think it will help with your use case.
Problem description
i am working on a Xamarin application that consumes a REST API written in Python flask.
The Xamarin application offers virtual shopping lists where user can collaborate on buying stuff they have on a shared list.
To improve the user experience, i want to be able to actively notify the user about finished items on the list.
Possible solutions:
Synchronous API polling from client side
Notifications are stored by the API in a relational database and have a flag indicating if the user received the notification already.
The API has an endpoint GET /users/:user_id/notifications/ that queries the database for notifications and returns a JSON response with those.
Advantages
fairly simple to implement
Problems
synchronous polling creates a huge amount of http requests
API service remains stateless, making a horizontal scaling with a loadbalancer easier
Websocket endpoint on the API
The API has an endpoint POST /users/:user_id/notifications/register which creates a websocket connection between client and API.
The connection is stored to a global array in which each entry maps a client id to a websocket connection.
When a new notification is created, the endpoint makes a lookup in the connection dictionary by comparing the owner id of the notification with the dictionary entries. The notification is sent to appropriate user through the websocket.
Notifications are stored in the database like in the first approach.
When a user calls the endpoint, a new websocket connection will be established first and upon success the API sends all unseen notifications from the database to the user.
Advantages
API can push notifications to clients asynchronously
Problems
When a user terminates the websocket connection his dictionary entry will persis
Retaining one websocket connection per user permanently adds additional overhead to the API
Horizontal scalability of the API is more difficult because the service is not stateless anymore (Websocket connection information saved in
RabbitMQ
The API uses a RabbitMQ service to send notifications to the client. Every client uses subscribes to his own notification queue to prevent the broadcasting of messages.
Advantages
API remains stateless
Problems
Notifications needs to be resend to the exchange when a user is offline
Amount of queues grows drastically
Additional costs for RabbitMQ service
High temporary load on the RabbitMQ service when many users come online in the same time
Final words
It would be interesting to hear the opinion of others.
I believe the active distribution of notifications from backen services to clients i a very common use case.
best,
D
I would use RabbitMQ and consume events forwarding them as push notifications. This will work while the user is not actively connected to the website and enhance the engagement with each user experience that will return to the website when notified for more information see How to setup basic web push notification functionality using a Flask backend or How to send push notifications to a browser in ASP.NET Core or Sending Notifications with Spring Boot, Angular, and Firebase Cloud Messaging this way the RabbitMQ will not wait until the user is back online. If the user is online you can forward the notification directly to the Xamarin application via WebSockets and a load balancer like NGINX that can handle many WebSockets in an optimized way.
Synchronous API polling from the client-side is the less preferred way since it overloads the webserver with requests while nothing was changed.
I don't think the scalability of WebSocket is a problem. You can scale up easily with pub/sub. The hotspot of long connections is a kind of serious problem.
For one-way communication, I would suggest Server sent event. In the end, it usually depends on what your team is confident with.
I can recommend on a different approach for API that provides JSON which is called GraphQL
It supports subscriptions capabilities that are pushed by the GraphQL API Server (using web sockets)
GraphQL is considered today to be better than RESTful API since its very flexible and you can get exactly the data you need with one query.
I'd like to build an app based on WCF service and Win8 as presentation layer. I will have messaging capabilities in the app so any user must see updates on the tile (when new messages arrive). As I understand I need to use "Push notifications service" mechanism somehow to update all client s tiles with new arrived messages? How would app work? It should call directly to WCF service and then WCF service should call to push notifications service, or firstly Win8 calls to notification service which calls to WCF? Can somebody clarify me how all this stuff can communicate with each other? Perhaps I should think about WCF Duplex approach? Is it possible to make WCF service to be Push notification service as well?
You can use the
The Windows Push Notification Services (WNS). Your app requests a notification channel. Then it will call the WCF service to send it that channel. The WCF service will send a POST request to the notification channel (which is a URI) in order to notify the app. The data of the request is in XML format (you can read about it in the link).
The Windows Push Notification Services (WNS) enables third-party
developers to send toast, tile, badge, and raw updates from their own
cloud service. This provides a mechanism to deliver new updates to
your users in a power-efficient and dependable way.
It involves these steps:
- Your app sends a request for a push notification channel to the Notification
Client Platform.
- The Notification Client Platform asks WNS to create a notification channel.
This channel is returned to the calling device in the form of a Uniform
Resource Identifier (URI).
- The notification channel URI is returned by Windows to your app.
- Your app sends the URI to your own cloud service. This callback mechanism is
an interface between your own app and your own service. It is your
responsibility to implement this callback with safe and secure web standards.
- When your cloud service has an update to send, it notifies WNS using the
channel URI. This is done by issuing an HTTP POST request, including the
notification payload, over Secure Sockets Layer (SSL). This step requires
authentication.
- WNS receives the request and routes the notification to the appropriate
device.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
How does it work? do these service also send push notification to a mobile device iphone/android? (even if the device is switched off?)
How does it work?
PubNub focus on HTTP connectivity (streaming, long-polling, polling etc.) that will work on all devices and anywhere.
Pusher use WebSocket between the client (web browser, mobile, tablet, desktop, any web-enabled device) and their service. They offer HTTP fallback for older devices or on networks that interfere with WebSocket connectivity.
do these service also send push notification to a mobile device iphone/android?
Both services support the ability to push data from one device to another via their service. This functionality is not the same type of functionality as Apple Push Notifications (APN), Google Cloud Messaging (GCM) or Microsoft Notification Protocol (MNP).
Only PubNub support native Push Notifications.
PubNub offer a larger number of client SDKs.
Pusher have a number of client libraries for mobile devices including Android and iPhone (iOS).
(even if the device is switched off?)
PubNub offer a form of message history for messaging delivered by mobile/web data connectivity. So upon reconnection missed messages will be delivered.
Pusher do not presently offer this functionality. So any messages that are sent during periods where the client is disconnected are lost.
If you use PubNub and their native Push Notification support then you get the delivery guaranteed by the underlying notification network that's used (Apple, Google or Microsoft).