Currently, I am working on chat integration and am considering SendBird and Vonage. Both of them are useful, but which one is faster and more useful?
Related
If you are trying to develop an interactive livestream application, you rely on ultra low (real-time) latency. For example for a video conference or a remote laboratory.
The two protocols, which should be suitable for this circumstances are:
RTSP, while transmitting the data over RTP
RTMP
*WebRTC: As I'm trying to give a bigger audience the possibility to interact with each other, WebRTC is not suitable. Because as far as I know it is not designed for a bigger audience.
My questions:
Which one should I choose for this use-case? RTSP/RTP or RTMP?
Which protocol delivers better results regarding end-to-end latency, session start-up time?
Which one consumes more hardware resources?
RTMP seems to use a persistent TCP connection. But which protocol is used for the transmission? It cannot be TCP, because this could not ensure real-time latency?
What are in general the pros and cons for using either of the protocols?
I did not find any comparison of these two protocols in scientific papers or books. Only that the famous mobile live-streaming app Periscope is using RTMP.
Other apps like Instagram or Facebook are for example providing text-based interaction with the streamer. If developers want to build the next "killer application" based on interactive live-streams: I think this question is essential to answer.
You make a lot of assumptions in your answer.
WebRTC: As I'm trying to give a bigger audience the possibility to interact with each other, WebRTC is not suitable. Because as far as I know it is not designed for a bigger audience.
That's simply not true. WebRTC doesn't know or care how you structure your applications server-side. There are plenty of off-the-shelf services for handling large group calls and low latency video distribution via WebRTC.
You should also know that for the media streams, WebRTC is RTP under the hood.
It cannot be TCP, because this could not ensure real-time latency?
Of course it can. There's some overhead with TCP, but nothing that prevents you from using it in a real time scenario. The overhead with TCP is minimal.
UDP is traditionally used for these sorts of scenarios, as reliability isn't required, but that doesn't mean TCP can't be used almost as performantly.
RTMP
RTMP is a dead protocol for Flash. No browsers support it. Other clients only support it for legacy reasons. You shouldn't use it for anything new going forward.
Only that the famous mobile live-streaming app Periscope is using RTMP.
Well, that's not a reason to do much of anything.
Which protocol delivers better results regarding end-to-end latency, session start-up time?
WebRTC
Which one consumes more hardware resources?
That's not the right question to ask. Your overhead in almost any other parts of the application is going to be far more than the transport overhead of the protocol used for distribution.
The real list of things you need to think about:
Client compatibility. What sort of clients must you support?
Do you really need low latency everywhere? Do you understand the tradeoffs you're making with that demand? Are you willing to destroy any sense of video quality and reliability for all your users if only a handful of them are going to be interactive?
What's your budget? Off-the-shelf solutions for distribution are much cheaper. If you can push off your stream to YouTube for non-interactive users, you can save yourself a ton of money. If you can't use existing infrastructure, be prepared to spend mountains of cash.
What are your actual latency requirements? Are you prepared to reduce the number of people that can use your application when these latency requirements cannot be met on crappier networks and mobile devices?
What are your quality requirements?
Where will you transcode video to a variety of bitrates?
Do your viewers need adaptive bitrate viewing?
Do you need to push streams to other platforms simultaneously?
Do you need to record the streaming for on-demand watching or going back in time?
You might also find my post here helpful: https://stackoverflow.com/a/37475943/362536
In short, check your assumptions. Understand the tradeoffs. Make decisions based on real information, not sweeping generalizations.
We are currently in the middle of a large infrastructure rebuild. We are replacing everything from the CRM to the ERP to the CTI.
We have decided to use WebRTC for the CTI. After working with WebRTC for a bit I really see the promise in this technology and started to think that maybe this is the way we want to go for our Webchat as well.
The premise behind this is to be able to add Voice / Video and Screensharing to our chat feature at some point in time.
Since WebRTC is not supported in Safari IE Edge Etc. I am thinking we may be just slightly ahead of ourselves in using WebRTC for text chat.
One thought would be to build it all out as WebRTC determine if the browser allows as default back to XMPP etc.
I have been researching this on my own and have found some options out there like talky.io but in this rebuild we are focusing on not having any third parties involved in our applications (We have had a couple go bye bye with no warning).
Is there a framework / library / open source project out there that tackles part or all of this task?
Is this task as daunting as I think it is going to be or am I overreacting?
Am I crazy, should be locked in a padded room and use an existing chat service?
talky is built ontop of https://github.com/legastero/stanza.io which includes a jingle/webrtc module
Take a look at the Jitsi project (specifically Jitsi Meet). A public version is running at meet.jit.si that you can try out; it uses webrtc for the voice / video, and Jingle / XMPP for the signaling. It is all open source, so you can be sure you won't lose access if the company goes under or something else bad were to happen. The Jitsi team runs it using the Prosody XMPP server; they make a good combination.
We have to develop a native mobile app for Instant Messaging using a SUITABLE protocol.
Also we are to develop a website for that application so that those who cannot login to mobile can continue their Instant Messaging through the website.
Later on, we would be adding the facilities of voice and video calls to the both native mobile app as well as the website.
Now my question is that, based on the above situation, which protocol we should go with?
I did some research on the internet about that and am unable to choose amongst XMPP, MQTT and MUMBLE.
Which one would be the best among them for the above criteria?
Also should I be using the same protocol for both the mobile app as well as the website? (no idea at all). Does choosing either the same or different protocols for native mobile apps as well as a website matter at all?
Consider me a novice here.
Your response would really mean a lot to me.
I am new to web development so correct me wherever I am wrong.
The answer to your question XMPP vs MQTT vs mumble really depends upon a number of factors that you did not describe in your question. Mainly on your non functional requirements.
XMPP is an xml based protocol originally designed as an instant messaging protocol. It has quite a high overhead in terms of number and size of messages in handling presence between all the clients. You could certainly base your implementation on XMPP. Google talk is based on XMPP and it uses XMPP to set up VOIP sessions using an extension to XMPP called Jingle.
MQTT is a general purpose low overhead publish/subscribe protocol. It is not specifically targeted at implementing instant messaging however Facebook uses it as the basis for their Facebook messenger. MQTT is a more efficient protocol in terms of its message size and its keepalive requirements so you might choose this if you plan to scale up to very large numbers of users or if you need your mobile clients to be highly responsive, even on low capability devices. If you choose MQTT then you will be left to design the "application level" protocol messages yourself, rather than following a standard. MQTT can certainly be used as the transport over which to set up voice chat and video streams.
You do not need to use the same protocol for mobile client versus website as long as your server side can appropriately process the interactions with mobile clients and web clients you could choose different protocols.
Facebook messenger does support voice messaging....
http://mashable.com/2013/02/21/facebook-voice-messages/
I have an iPhone game (Combination), and in the next version I would like to set up a server, where users (via the app) can submit which levels they have completed, and see how other users are doing. At this point I don't intend that users will need usernames and passwords, just a simple submit data, get back data.
I know very little about server-based language and databases, but I've heard lots of horrible things that can happen if you get it wrong. What would be the best system to design a simple, lightweight, secure database in?
How about having a look at Onyx Online or OpenFeint?
Onxy Online is from the makers of Trism, and they say, "the XBox Live Arcade ecosystem brought to the iPhone". I wrote this kind of system into Trism as a case study, and it's been a complete success. Since Trism launched in July, we've been hard at work adapting this online code for use in any iPhone game, and the results are stunning. What we're going to do is allow any developer to insert the Onyx code into their game, which will instantly enable online scoring, achievements, leaderboards, and customized forums."
OpenFeint is from the developers of Aurora Feint. From the press release:
"OpenFeint allows any iPhone game to add player profiles, buddy lists, walls, newsfeeds and real-time chat rooms allowing the game to build a real community around itself with ZERO operations overhead and minimal development time. OpenFeint consists of a server and a client. The OpenFeint Server is fully compatible with Google’s OpenSocial REST API and will be accessible through the OpenFeint client code library and sample UI code from Aurora Feint Inc. Indie developers do not have to operate the servers, which will be hosted Aurora Feint’s data center.
In a first for iPhone games, iPhone game developers will have the ability to reduce over 2 months of development work to 1 day, and completely eliminate back-end server operations, while offering their players an extensive set of customizable social and community building features:
Profiles: Players can upload an avatar photo or take one with their iPhone camera.
Walls: Each player gets a wall where other players can leave comments and view wall-to-wall conversations
Asynchronous Real Time Chat Rooms for meeting other players, sharing tips, strategies and experiences within each game community
Buddy List: Players can friend other players within their community or across the iPhone gaming community
Newsfeeds: Players can keep in touch with all of their friends’ activities (wall comments, actions in games, befriending people)
Global Community Chat Rooms for players to discuss recommendations, tips, and reviews of other games on the iPhone"
Have you used Java/C#/Perl/Python any other "server side language?" Are you going to be hosting the server-side yourself, or are you looking at hosting companies? Your decision might come down to how you intend to host your server-side stuff, and what capabilites your hosting company offers or what you are comfortable with.
Java or C# are really powerful server-side languages, but hosting these can take a little more work (and money?).
Java might be a good starting point, because you can setup Tomcat yourself and try hosting some web-services. MySQL is a good database to start with, but there are even more lightweight database alternatives. There might be a bit of a learning curve with any of these.
Have you heard of ICE touch? ICE is a middleware for network communication and has a basic persistence support. It supports every major platform:
iPhone as a client
Android as a client
Objective-C Mac OS X as client/server
C++ Linux as client/server
Java [any OS] as client/server
C#/C++, Windows .NET (with Silverlight) and native as client/server
I evaluated it some time ago and was surprised about its maturity, good documentation and example code. They name Skype as one of their customers.
As a start I would recommend to have a look at their example chat application. You can run a Java server, connect with your iPhone, your G1 and your Silverlight client and have a chat. Pretty impressive interoperabilty!
Here comes the drawback: GPL (you cannot link against it without being GPL yourself) or commercial (individual pricing).
I would also recommend you to use an online database service such as Viravis , DabbleDB or Zoho Creator. Almost all of these kinds of services have required integration capability to work with such a client as Web, Desktop, Windows Mobile or IPhone.
Java/Javascript is the defacto combo for most developers because of the Java support for every platform. Java Script has more than a few "issues"
The rest of the herd uses .NET (with its attendant 100MB run time bloatware that changes every 9 months)
php,pearl,ruby etc are good for server side, but if you want to use code, the best solution is probably C/C++ (or similar) and CGI/FastCGI.
This allows you to write communication algos once and use them on both ends. Any encryption/compresssion sim same.
I'm thinking about using semantic (web) technologies like RDF and OWL in an application on mobile devices. Currently I'm targeting android, but I'd also be interested in the possibilities on the iPhone and on J2ME.
I would like to use a library instead of implementing everything from scratch.
I know that there are some libraries/frameworks like Jena, Redland, Protégé but they don't state on which platforms they are known to work.
Having a dynamic object model and parsing from and to XML are must-haves for me.
I'd also like to use reasoning, but I've been told it was rather computing-intensive, so that's only a nice-to-have.
For all platforms mentioned, the question can be interpreted as
Is it possible in theory? (especially for J2ME I'm not sure)
Are there libraries that are known to work on those platforms?
Is the performance on a mobile platform good enough for real world usage?
You wrote you want J2ME, but other readers might be interested in C#.
Mono makes C# available on iPhone and Android. Once that is done, you can use ROWLEX to deal with RDF and OWL. You might consider reading this Stackoverflow question.
Maybe look into IYOUIT. It is a
mobile application developed in
Python, and running on Nokia Series 60
phones.
It uses OWL and reasoning. You can read the details in this paper.
There's Jena port to Android platform here.
http://code.google.com/p/androjena/
If this is a client-server type application and you have some control over the server, I would do the semantic web stuff server-side, and hand the relevant information to your view client on the mobile device.
A more general answer to your question title is Mosembro, a browser for Android that utilizes Microformats for semantic data. It doesn't do any non-trivial computations with the data, however.
if you have no limit as to use a certain framework, you can use REST api to handle server-client interactions.
more information here.