Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
1) websocket protocol can send and receive voice and video call?
2) web RTC can send and receive text message ?
3) websocket or webRTC whom has more secure for use in chat application ?
4) what is difference between video call and streaming video ?
5) websocket or webRTC whom are faster in communication ? ( send and receive text message , voice and video call )
6) can we use from websocket and webRTC in same application together ?
Thank you very much .
Websocket is a protocol which is based on HTTP, meaning that you can either send or receive any data via a websocket(wss), but the downside is that websocket can't capture video data.
You can use webrtc.datachannel to send or receive any data, webrtc.datachannel is based on P2P (Peer-to-peer). You can visit this datachannel.
You can use wss to make websocket more secure, plus you can choose wss to build a websocket connection. WebRTC is based on DTLS, so it is more secure(for packet sniffing). On the other hand, since WebRTC utilizes P2P, a user can trace another user's IP Address. You must use WebRTC via HTTPS or wss, or else it won't work.
Websocket needs a server, where WebRTC is a P2P connection, so WebRTC is faster.
Yes, you need a signal server to exchange SDP for WebRTC. You can use websocket to build the signal server.
Related
I am new to this !
I am working for a chat application which requires text+ video chats.
I explored Socket.io initially and found it very handy to develop text based chatting application (WEB).
While exploring the Video chat element i came across WebRTC -RTCDataChannel for sending out arbitrary data across connected peers.
My Chat Server( preferably NodeJS ) will be serving the connections for peers, along with saving text chat history.
Confusion:
Should I use Socket.io-MyChatServer as the Signalling server also? [Possible?] , Or
Should I use RTCDataChannel for signalling server? , Or
Simply forget Socket.io and consider WebRTC for both !
Thanks in advance :)
Well WebRTC data channels and web sockets are different and complementary concepts in the case of peer connections.
In order to open a data channel you first need a P2P connection. In order to establish a P2P connection, you need a signaling server. So, sockets are used for that purpose, to exchange the metadata necessary to create a P2P connection. First, through sockets you establish a peer to peer connection and only after that you can use data channels.
As for using the same chat server as signaling server is up to you. WebRTC let the signaling server architecture be defined by the developer. It's a blackbox.
So, no you can't use data channels as signaling, as you can see.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What are merits of MQTT over WebSocket compared to direct MQTT?
I'm considering using MQTT in my project and so I want to know why some people choose MQTT over WebSocket instead of direct MQTT.
You should only need to run MQTT over websockets if you intend to publish/subscribe to messages directly from within webapps (in page).
Basically I would run pure MQTT for everything and only add the websockets if you actually need it.
For all the non-browser languages the MQTT client libraries only use native MQTT. For Javascript there is both a pure MQTT library and the Paho in page library that uses websockets.
Edit:
The firewall tunnelling use case is a valid reason to use MQTT over websockets and since writing this answer more of the none web/JavaScript client libraries have added support
Two main reasons for using MQTT over Websockets (which effectively means going over HTTP/HTTPS):
Web apps (those running in a browser - e.g. written in JavaScript)
Any other applications that don't want to use the 1883/8883 port and want to go over HTTP/HTTPS instead - this could be so that there is less of a chance of being blocked by a firewall (e.g. in a corporate network), as most firewalls will let HTTP traffic through
If you don't need or worry about the above, use "direct" MQTT:
it is more efficient
there are more client libraries for various languages that work with "direct" MQTT
MQTT is a protocol which supports following:
Provides publish/subscribe mechanism
Quality of Service policy
Have minimal overhead in communication
Specifically designed for narrowband communication channel and
constrained devices.
Depending upon the device there is an implementation available.
Browser : It uses websockets. Websocket provides browsers with a capability to establish a full duplex communication. There is Javascript library to implement MQTT functionality, see Eclipse Paho JavaScript Client
Android : Their is a MQTT client library written in Java for developing applications on Android. See Eclipse Paho Android Service
So it depends on device that is going to use this functionality. For standards and specifications please visit MQTT Version 5.0
Hoping this helps.
Cheers !
MQTT over websockets is perfect if ever a certain webpage is the sending or the receiving MQTT client.
A good summary of the capabilities of MQTT over websockets can be found here.
MQTT over web sockets is also helpful if the application is running behind a firewall that allows only 443 and 80 traffic. And, you have no control over the policies of the firewall.
MQTT Broker:
The counterpart of the MQTT client is the MQTT broker. The broker is at the heart of any publish/subscribe protocol. Depending on the implementation, a broker can handle up to thousands of concurrently connected MQTT clients.
MQTT Client:
When we talk about a client, we almost always mean an MQTT client. Both publishers and subscribers are MQTT clients. The publisher and subscriber labels refer to whether the client is currently publishing messages or subscribing to messages (publish and subscribe functionality can also be implemented in the same MQTT client).
WebSocket:
We have learned in the MQTT Essentials that MQTT is ideal for constrained devices and unreliable networks. It’s also perfect for sending messages with a very low overhead. It would be quite nice to send and receive MQTT messages directly in the browser of a mobile phone or in general. This is possible by MQTT over WebSockets.
You can use a third-party protocol. PAHO, EMQTT, VerneMQ.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
So I'm looking to build a chat app that will allow video, audio, and text. I spent some time researching into Websockets and WebRTC to decide which to use. Since there are plenty of video and audio apps with WebRTC, this sounds like a reasonable choice, but are there other things I should consider?
Feel free to share your thoughts.
Things like:
Due to being new WebRTC is available only on some browsers, while WebSockets seems to be in more browsers.
Scalability - Websockets uses a server for session and WebRTC seems to be p2p.
Multiplexing/multiple chatrooms - Used in Google+ Hangouts, and I'm still viewing demo apps on how to implement.
Server - Websockets needs RedisSessionStore or RabbitMQ to scale across multiple machines.
WebRTC is designed for high-performance, high quality communication of video, audio and arbitrary data. In other words, for apps exactly like what you describe.
WebRTC apps need a service via which they can exchange network and media metadata, a process known as signaling. However, once signaling has taken place, video/audio/data is streamed directly between clients, avoiding the performance cost of streaming via an intermediary server.
WebSocket on the other hand is designed for bi-directional communication between client and server. It is possible to stream audio and video over WebSocket (see here for example), but the technology and APIs are not inherently designed for efficient, robust streaming in the way that WebRTC is.
As other replies have said, WebSocket can be used for signaling.
I maintain a list of WebRTC resources: strongly recommend you start by looking at the 2013 Google I/O presentation about WebRTC.
Websockets use TCP protocol.
WebRTC is mainly UDP.
Thus main reason of using WebRTC instead of Websocket is latency.
With websocket streaming you will have either high latency or choppy playback with low latency. With WebRTC you may achive low-latency and smooth playback which is crucial stuff for VoIP communications.
Just try to test these technology with a network loss, i.e. 2%. You will see high delays in the Websocket stream.
WebSockets:
Ratified IETF standard (6455) with support across all modern browsers and even legacy browsers using web-socket-js polyfill.
Uses HTTP compatible handshake and default ports making it much easier to use with existing firewall, proxy and web server infrastructure.
Much simpler browser API. Basically one constructor with a couple of callbacks.
Client/browser to server only.
Only supports reliable, in-order transport because it is built On TCP. This means packet drops can delay all subsequent packets.
WebRTC:
Just beginning to be supported by Chrome and Firefox. MS has proposed an incompatible variant. The DataChannel component is not yet compatible between Firefox and Chrome.
WebRTC is browser to browser in ideal circumstances but even then almost always requires a signaling server to setup the connections. The most common signaling server solutions right now use WebSockets.
Transport layer is configurable with application able to choose if connection is in-order and/or reliable.
Complex and multilayered browser API. There are JS libs to provide a simpler API but these are young and rapidly changing (just like WebRTC itself).
webRTC or websockets? Why not use both.
When building a video/audio/text chat, webRTC is definitely a good choice since it uses peer to peer technology and once the connection is up and running, you do not need to pass the communication via a server (unless using TURN).
When setting up the webRTC communication you have to involve some sort of signaling mechanism. Websockets could be a good choice here, but webRTC is the way to go for the video/audio/text info. Chat rooms is accomplished in the signaling.
But, as you mention, not every browser supports webRTC, so websockets can sometimes be a good fallback for those browsers.
Security is one aspect you missed.
With Websockets the data has to go via a central webserver which typically sees all the traffic and can access it.
With WebRTC the data is end-to-end encrypted and does not pass through a server (except sometimes TURN servers are needed, but they have no access to the body of the messages they forward).
Depending on your application this may or may not matter.
If you are sending large amounts of data, the saving in cloud bandwidth costs due to webRTC's P2P architecture may be worth considering too.
Comparing websocket and webrtc is unfair.
Websocket is based on top of TCP. Packet's boundary can be detected from header information of a websocket packet unlike tcp.
Typically, webrtc makes use of websocket. The signalling for webrtc is not defined, it is upto the service provider what kind of signalling he wants to use. It may be SIP, HTTP, JSON or any text / binary message.
The signalling messages can be send / received using websocket.
Webrtc is a part of peer to peer connection.
We all know that before creating peer to peer connection, it requires handshaking process to establish peer to peer connection.
And websockets play the role of handshaking process.
Websocket and WebRTC can be used together, Websocket as a signal channel of WebRTC, and webrtc is a video/audio/text channel, also WebRTC can be in UDP also in TURN relay, TURN relay support TCP HTTP also HTTPS.
Many projects use Websocket and WebRTC together.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would like to build a app with private chat powered by SockJS using Vert.X. I quickly ran into limitation of SockJS because of it's simplistic API and multiplexing doesn't seem to be the answer (see: https://groups.google.com/d/topic/sockjs/cO7lnH07RCE/discussion ).
Would EventBus Bridge be the right tool? Each client binds to a unique address, and VertX server can respond to them, or ignore them by default if not recognized?
Is that the intent of EventBus Bridge?
Can permit rules be changed once the SockJSBridge is started?
Randomized token (UUID?) can also be added to inbound rule "match" to simulate how session would work.
Is this reasonable? or has this been wildly used?
The EventBusBridge lets clients (browsers via SockJS) talk with other subscribers on the EventBus. That means you can send messages directly with Server-side Services or other clients.
You cannot change the permit/firewall rules for the bridge dynamically. But with regular expressions and using UUIDs, you should be able to implement a chat quite easily. Let me give you an example:
The server listens on address chat-server. The outbound setting in the bridge is set to { "address_re" : "chat-clients\..*" }. Every client registers a handler on chat-clients.<some_UUID_for_this_client> and tells the server to send messages addressed to the client to the registered address.
We have written a chat module in Scala, which you can use as a reference.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am using nokia 5233 GSM Modem with SMS Caster. I want to send bulk SMS to my clients but my GSM Modem is very slow to do that. It is sending only 10 to 12 SMS Per minutes. I want to use my cell number and sim to send SMS but with very high speed. How cold I find an altrnate to my Cell's GSM Modem.
GSM Modems or phones are not designed for sending bulk messages at high rate. You will need to either get in touch with some bulk SMS providers or virtual-number providers that lets you do this. If you need a phone number to appear as sender-id in India, you will need to do this using a virtual number only.
I've been trying to send bulk messages via a GSM modem and found that the GSM network architecture makes clients incapable of sending more than ~10 sms/minute or, allegedly, ~30 sms/minute using GPRS. Exact limits depend on the modem/device, provider and reception. To send more, as was suggested already, you need to look into a (paid) gateway service connected directly to a messaging centre.
i had experience sending 40000 sms at once. to do this contact gsm operators directly. they can send about 50 sms per second via direct connection to sms center. usualy they have web interface connected to sms center, have ways to provide basic data about people (gender, day of birth etc). You upload phone database to web interface and fire up your delivery. you get wholesale price for your delivery
Yes, it is true that GSM/GPRS modems cannot send messages at a high rate. You would need access to an SMS Centre or SMS Gateway as mentioned here!
This is because of synchronous messaging model.
If you want to send 100 messages, only one thread will be executing this messaging sending activity.
In case you use python there is a multiprocessing module
http://docs.python.org/library/multiprocessing.html.
There will be similar method in your programming language.