Does anyone know if OpenToks sendSignal() method is peer to peer? Or does it get routed through OpenTok's servers? We are looking to send image and video files P2P, but the signaling method seems a bit slower than webRTC's native data channel. I'm wondering if there is something extra happening under the hood.
From the documentation, you should be able to send to a specific end: https://tokbox.com/developer/sdks/js/reference/Session.html#signal. What you need to do is to specify a Connection object.
Related
I am writing a frontend application that needs to know what is the current transfer rate with the server. When using HTTP, this is easy enough thanks to the performance API. You can access many measurement of the HTTP call by just using
performance.getEntriesByName(url);
However it seems WebSockets are not covered by this API. So I have been trying to find a way to do the same without it.
It seems the MessageEvent has a timestamp which indicates the time at which the event is created. However, there isn't much documentation about when that MessageEvent is created. Is it at the reception of the first byte (which I hope) or is it once the whole message is downloaded (which is probably the case). Does anyone happen to know if there is more detail on how WebSockets messages are managed by browser?
More generally, how do you measure your WebSockets transfer rate from the frontend without server side help?
I am building a new application that receives data from a number of external devices and needs to make it available to a number of different components. ZeroMQ seems purpose-built for the "data bus" aspect of my architecture.
I recently became aware that zmq STREAM sockets can connect to native TCP sockets and send/received messages. Using zmq throughout has a lot of appeal, but I have one problem that I don't know how to get around.
One of my devices needs to be set up. That is, I connect a socket to it, send it some configuration information, then sit back and wait for it to send me data. The device also has a "reset" capability (useful in some contexts), that requires re-sending the configuration information. Doing this depends upon having visibility to the setup/tear-down stage of the socket interface. I need to know when a new connection is established, so I can send the necessary configuration messages.
It seems that zmq is purposely designed to shield me from that knowledge. Is there a way to do what I want? Or should I just use regular sockets for this interface?
Well, it turns out that reading (the right version of) the fine manual can be instructive.
When a connection is made, a zero-length message will be received by the application. Similarly, when the peer disconnects (or the connection is lost), a zero-length message will be received by the application.
I guess all that remains is to disambiguate between connect and disconnect. Still looking for advice from the community, if others have dealt with this situation before.
Following up on your own answer, I would hesitate to rely on that zero length connect/disconnect message as your whole strategy - that seems needlessly fragile. It's not clear to me from your question which end is persistent and which end needs configuration information, but I expect that one end knows it's resetting and reconnecting, and that end needs configuration information from the peer, so it should ask for it with a message when it needs it, to which the peer responds with the requested information.
If the peer does not yet have the required configuration information before it receives some other message, it could either queue up that work or it could respond back with the need for the config, and then have the rest of the network handle that need appropriately.
You shouldn't need stream/tcp sockets to make that work, it should work with more standard ZMQ socket types, you just need to build the robustness into your application rather than trying to get it for free from TCP/socket actions.
If I've missed your point, and what I'm suggesting won't work for some reason, you will have to give more specific information about your network topology for anyone else to understand what a suitable solution might be.
I see that there is the File Writer filter available in DirectShow, which can either write a stream (data of major type MEDIATYPE_Stream) to a [local] file or publish it on a URL. You'd think the latter is what I want, but from what I understand, it creates a HTTP endpoint exposing the stream on the specified URL. For remote clients that will connect and consume this stream. Basically, a streaming server. Which is not what I want.
What I am looking for is a filter that connects to a remote HTTP server and uploads the data it receives upstream over HTTP using say, POST or PUT method.
Is there something like this available?
I'd imagine this filter, just like the File Writer filter, take a MEDIATYPE_Stream on its input pin, and just like File Writer, be a "renderer" filter -- not having any output pins.
I am not an expert with DirectShow, but I have some experience with it and have played around with Graph Studio Next just to see what connects where and how. Anyhow, please feel free to point out any glaring conceptual errors I am displaying here. I sure hope this is not a case of an XY problem.
I'm trying to understand whether the HTML5 Web Notifications API can help me out, but I'm falling short in understanding how it works.
I'd like user_a to be able to send user_b a message within my webapp.
I'd like user_b to receive a notification of this.
Can the web notifications API help here? Does it let me specifically target a user (rather than notify everyone the site has been updated_? I can't see how I would create an alert for one person.
Can anyone help me understand a little more?
The notifications API is client side, so it needs to get events from another client-side technology. Here, read THIS: http://nodejs.org/api/. Just kidding. Node.js+socket.io is probably the best way to go here, you can emit events to one or all clients (broadcast). That's a push scenario. Or each user could be pulling their notifications from the server.
HTML5 Web Notifications API gives you ability to display desktop notifications that your application has generated.
What you are trying to achieve is a different thing and web notification is just a part of your scenario.
Depending upon how you are managing your application, for chat and messaging purpose as humbolight mentioned, you should look into node.js. it will provide you the necessary back-end to manage sending and receiving messages between users.
To notify a user that (s)he has received a message, you can opt for ajax polling on client side.
Simply create a javascript that pings the server every x seconds and checks if there is any notification or new message available for this user.
If response is successful, then you can use HTML5 notification API to show a message to user that (s)he has a new message.
The main problem with long polling is server load, and bandwidth usage even when there are no messages, and if number of users are in thousands then you can expect your server always busy responding to poll calls.
An alternate is to use Server Sent Events API, where you send a request to server and then server PUSHES the notifications/messages to the client as soon as they are available.
This reduces the unnecessary client->server polling and seems much better option in your case.
To get started you can check a good tutorial at
HTML5Rocks
What you're looking for is WebSocket. It's the technology that allows a client (browser) to open a persistent connection to the server and receive data from it at the server's whim, rather than having to "poll" the server to see if there's anything new.
Other answers here have already mentioned node.js, but Node is simply one (though arguably the best) option for implementing websockets on your server. You might also be comfortable with Ratchet, which is a websocket server library for PHP, or Tornado which is in Python.
How you handle your real-time communication is up to you. Websockets are merely the underlying technology that you can use to pass data back and forth. The client side of this will be fairly easy, but on the server side, you'll need a mechanism for websocket handlers to get information from each other. Look at tools like ZeroMQ for handling queues, and Memcached or Redis to handle large swaths of data which don't need to be stored permanently.
We have a web app making use of websocket with netty. We are trying to push through a large stream of data and noticing that once we hit about 300-400 responses a second, the channel begins to get marked as NOT_WRITABLE and we are unable to send some of the responses.
It seems as though netty is waiting for an ack on the socket. Is there any way to disable that, or any way to speed it up to be able to handle more? The javascript implementation in chrome is pretty bare-bones and it doesn't seem like there's much we can do to increase performance from that side.
Seems like your write faster then the data can be "send out" to the client. You can try to increase the write watermark. See [1].
Als you may want to experiment with some TCP opts like "tcpNoDelay" and "sendBufferSize". See [2]
[1] http://static.netty.io/3.5/api/org/jboss/netty/channel/socket/nio/NioChannelConfig.html#setWriteBufferHighWaterMark(int)
[2] http://static.netty.io/3.5/api/org/jboss/netty/channel/socket/SocketChannelConfig.html