I want to get all publisher or subscriber or stream object from a session object, Is it possible?
TokBox Developer Evangelist here.
As Fran mentioned, there is no API that exposes all of the streams in a session so you would have to store that data locally. You can do this by listening to the streamCreated and streamDestroyed events on the client side or by using the session monitoring feature on the server side. Session monitoring allows you to receive the following events via a webhook:
connectionCreated
connectionDestroyed
streamCreated
streamDestroyed
Right now there is no API to retrieve publishers or subscribers data. You can get session information and streams:
https://tokbox.com/developer/rest/#get-stream-info
Related
I've seen the sample app on github. There is an explicit "Start Broadcasting" button that does what it sounds like (starts broadcasting rtmp).
I'd like not to have an explicit button. I'd like to start broadcasting when the first user in a session publishes his or her camera. So if 5 users connect to the session, call broadcast when the first of them publishes a stream, but not when any of the others do.
Can I query the session and know whether it is live streaming currently? What is the best practice here? Thanks.
TokBox Developer Evangelist here.
You cannot query the number of active streams in a Session, you would have to store that information on your own as events are being dispatched. Please see this SO answer for more details: #OpenTok how enumerate streams in a session?
As for broadcasting, you can start broadcasting programmatically when the first person starts publishing instead of using a visual component to trigger the call. For example, on the client side, you can listen for the streamCreated event and then send a request to your application server to start the broadcast. Your application server would then have to make a the startBroadcast call to OpenTok via a Server SDK or using the REST API.
Alternatively, you could use Session Monitoring to listen to Stream and Connection events on the server via a webhook, to start the broadcast.
To find out more on how OpenTok Broadcasting works, I recommend checking out the following resources:
OpenTok Broadcasting Developer Guide
OpenTok Broadcasting Webinar
Both the Solace queue and my program are subscribing to #LOG/INFO/SUB_ADD/DEVICE/ID/123.
When a new device which connects and subscribe to DEVICE/ID/123, both of them can successfully receive the subscribe event.
But, if I set subscription as #LOG/INFO/SUB_ADD/DEVICE/ID/>, only the solace queue receives the event.
Why can't my program receive the subscription event?
The problem persists even after my program sets it's subscription to #LOG/>.
One possible problem here is that there is an ACL rule preventing your application to subscribe to one or more topics in #LOG/INFO/SUB_ADD/DEVICE/ID/>. This can be easily verified with show log acl subscribe-topic.
If this is not the case, please revert back with the CLI outputs of show client <client-name> stats detail and show client <client-name> subscriptions to look further into the issue.
We are currently implementing a simple chat app that allows users to create conversations and exchange messages.
Our basic setup involves AngularJS on the front-end and SignalR hub on the back end. It works like this:
Client app opens a Websockets connection to our real-time service (based on SignalR) and subscribes to chat updates
User starts sending messages. For each new message, client app calls HTTP API to send it
The API stores the message in the database and notifies our real-time service that there is a new message
Real-time service pushes the message via Websockets to subscribed Clients
However, we noticed that opening up so many HTTP connections for each new message may not be a good idea, so we were wondering if Websockets should be used to both send and receive messages?
The new setup would look like this:
Client app opens a Websockets connection with real-time service
User starts sending messages. Client app pushes the messages to real-time service using Websockets
Real-time service picks up the message, notifies our persistence service it needs to be stored, then delivers the message to other subscribed Clients
Persistence service stores the message
Which of these options is more typical when setting up an efficient and performant chat system? Thanks!
You don't need a different http or Web API to persist message. Persist it in the hub method that is broadcasting the message. You can use async methods in the hub, create async tasks to save the message.
Using a different persistence API then calling signalr to broadcase isn't efficient, and why dublicate all the efforts?
Pusher service works as illustrated here:
Does it make sense to use it in reverse direction (and switched data channels)? My use case is as follows:
end users (actually mobile, not browser) send messages to Pusher via HTTP-based REST API
my firewalled machine is connected to Pusher via WebSockets API, subscribes channel and receives messages in realtime
This way I can work with Sandbox plan (only 1 persistent connection is used) but mobile app must contain Puser app key.
From what I understand, anyone can use this key to register subscribe same message stream via websockets. Is there a reverse mode, where receiving messages requires knowing the secret? Maybe other service would suit better?
A more secure solution would be for the mobile clients to use client events. Client events can only be triggered on private channels where the subscription to the channel has to be authenticated.The authentication requests should got to an HTTP endpoint that you control so that you can validate the subscription request.
You firewalled machine can either then have a WebSocket connection and receive the client events over that connection. Or it could receive the client events via client event WebHooks if it exposes an HTTP endpoint.
I have a Java application which I make available via RESTful web services. I want to create a mechanism so clients can register for notifications of events. The rub is that there is no guarantee that the client programs will be Java programs and hence I won't be able to use JMS for this (i.e. if every client was a Java app then we could allow the clients to subscribe to a JMS topic and listen there for notification messages).
The use case is roughly as follows:
A client registers itself with my server application, via a RESTful web service call, indicating that it is interested in getting a notification message anytime a specific object is updated.
When the object of interest is updated then my server application needs to put out a notification to all clients who are interested in being notified of this event.
As I mentioned above I know how I would do this if all clients were Java apps -- set up a topic that clients can listen to for notification messages. However I can't use that approach since it's likely that many clients will not be able to listen to a JMS topic for notification messages.
Can anyone here enlighten me as to how this problem is typically solved? What mechanism can I provide using a RESTful API?
I can think of four approaches:
A Twitter approach: You register the Client and then it calls back periodically with a GET to retrieve any notifications.
The Client describes how it wants to receive the notification when it makes the registration request. That way you could allow JMS for those that can handle it and fall back to email or similar for those that can't.
Take a URL during the registration request and POST back to each Client individually when you have a notification. Hardly Pub/Sub but the effect would be similar. Of course you'd be assuming that the Client was listening for these notifications and had implemented their Client according to your specs.
Buy IBM WebSphere MQ (MQSeries). Best IBM product ever. Not REST but it's great at multi-platform integration like this.
We have this problem and need low-latency asynchronous updates to relatively few listeners. Our two alternative solutions have been:
Polling: Hammer the list of resources you need with GET requests
Streaming event updates: Provide a monitor resource. The server keeps the connection open. As events occur, the server transmits a stream of event descriptions using multipart content-type or chunked transfer-encoding.
In the response to the RESTful request, you could supply an individualized RESTful URL that the client can monitor for updates.
That is, you have one URL (/Signup.htm, say), that accepts the client's information (id if appropriate, id of object to monitor) and returns a customized url (/Monitor/XYZPDQ), where XYZPDQ is a UUID created for that particular client. The client can poll that customized URL at some interval, and it will receive a notification if the update occurs.
If you don't care about who the client is (and don't want to create so many UUIDs) you could just have separate RESTful URLs for each object that might want to be monitored, and the "signup" URL would just return the correct one.
As John Saunders says, you can't really do a more straightforward publish/subscribe via HTTP.
If polling is not acceptable I would consider using web-sockets (e.g. see here). Though to be honest I like the idea suggested by user189423 of multipart content-type or chunked transfer-encoding as well.