Does Google Talk or GTalk support real-time text (RTT)? If it does is there any example or a snippet of it somewhere? I have seen the proposal of Mark Rejhon, but didn't find any solid proof that GTalk supports RTT.
XEP-0301: Real-Time Text is a client-to-client protocol, and does not require server support.
If you are asking about Google's clients, I do not know that any of them support RTT - it is a very new XEP and currently still experimental.
There's a web-based RTT chat client at http://tap.gallaudet.edu/rtt/
There's a Windows RTT chat client at http://www.realjabber.org/
Try it now - it works over Google's server. Just log on using your GMAIL account & your existing buddy list shows up, and you can chat RTT right away. Google's own GMAIL client does not support RTT, but Google's Talk Servers supports RTT well. A properly implemented XMPP network (jabber.org) supports RTT too. So that means any third-party software (supporting XEP-0301) can implement it. You just log on using your Google Talk ID or Jabber compatible ID.
No server modifications are needed; it's a client based protocol that works perfectly through Google Talk's own servers. The RTT goes through the existing Google Talk servers as extension data; via the same network routing as existing XMPP messages (Google Talk message delivery).
If you try to chat between an RTT client (e.g. Gallaudet or RealJabber) and Google Talk, the line-by-line messages make it through, the typing just doesn't show up in real-time.
P.S. The standard is being upgraded from Experimental in the near future.
Related
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 app with rails serving as a backend server.
Now I need to implement a chat functionality using sockets connections.
A lot of examples show you how to implement chat using sockets in browser.
What I need here is how I can implement an application where you create socket server in the rails app , and the client in iphone app which listens to the channel I give them.
I tried using faye(examples given only how to implement client in the browser) and using fayeObjC library for iphone to create client, but am not able to listen to the channel from this library.I know I must be implementing it wrong here.
I'll share my code also here, but first I need to know is there a better solution than this?
Also I appreciate some links to some examples where socket server is in rails and clients are iphone app.
Appreciate any help and mostly need a right direction to implement it.
Update
I tried the faye combination again and it worked.Although still looking for more solutions.
You can check about TCP sockets:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Chat Application Using Ruby
http://quickblox.com/modules/chat/
http://caydenliew.com/2011/11/ios-mac-os-communication-with-asyncsocket/
http://www.macresearch.org/cocoa-scientists-part-xxix-message
Next link is a comprehensive Networking Guide - Using Internet Sockets
You must keep in mind two major problems to peer-to-peer communications (Chat): reachability and how to receive new messages while your application is in the background (get notifications).
For the last you can use APNS approach: an invisible notification will be pushed to the iPhone indicating that a new message is ready to be read. So your app will make a request for unread messages (what app like WhatsApp does).
Besides TCP sockets you could use websockets (HTTP - so there are no firewall problems).
Best in class - Socket.IO.
Here you will find the wiki https://github.com/learnboost/socket.io/wiki (you will find there an extension for Ruby also)
Here an example for iOS chat client for socket.io & node.js backend
Jabber
Another option: XMPP - "stands for eXtensible Messaging and Presence Protocol. Such a protocol is open-standard and oriented to message exchange (builds and maintains by Jabber community). Message exchange happens near real time, so it is an ideal infrastructure to build chat-like applications. The protocol also implements a mechanism to notify presence information (whether a user is online or not) and the maintenance of a contact list. XMPP is a thorough protocol, which has been adopted also by big companies like Google to build their Instant Messaging service."
Here you will find all about developing a Jabber Client for iOS (enable users to sign in, add buddies, and send messages; how to install and configure a jabber server, create accounts, and interact with the server from an iOS application http://mobile.tutsplus.com/tutorials/iphone/building-a-jabber-client-for-ios-server-setup/
I know that SocketRocket by square is a strong native Objective-C library. But it doesn't offer the channel abstraction you seem to be looking for.
If you would consider outsourcing the WebSocket connections then you could use a hosted service like Pusher, who I work for. You can publish messages (trigger events) on channels using the pusher-gem. And you can subscribe to channels and receive messages using one of Pusher's Objective-C libraries.
Other solutions will also have Objective-C libraries and you can find a list of them via this realtime web tech guide.
I have an idea of an application that involves a "chat feature", basically an ability for people to chat with each other. Since sending messages through a server would be slow (plus it would be pretty bad having to check the server every second if you have new messages) I want to use sockets to have peer to peer chat ability instead of going through a server.
My 2 questions:
1) Is socket programming the most optimal way to develop a chat program? I know there is push notification service, but I don't think it can be used for a chat program too well. Going through a server seems kind of bad if you imagine 5,000 people chatting and having to poll the server every second.
2) Will Apple have issues approving an app that has peer to peer chat program that uses sockets?
Thank you.
Sockets are indeed appropriate. But you are better off with a client/server approach rather than a P2P approach.
Having worked on a very well known instant messaging service for many years, I can tell you absolutely that going through a server is not slow - as long as your server is not slow.
Client/server has lots of advantages. Namely, it's not as difficult as any sort of P2P connectivity where such issues as NATs and Firewalls make direct socket connections difficult and unreliable. Besides, you would need a messaging service anyway for clients to exchange IP addresses.
Your stated assumption that a client or server would have to "poll" is not how scalable systems work. You should use a persistent TCP socket and look at scaling a socket service up though any of the available async methods that exist today. select(), poll(), epoll on Linux, and IO Completion Ports on Windows are all techniques for having thousands of sockets simultaneously connected without periodic polling.
My suggestion - just deploy an XMPP/Jabber server. Most implementations scale up nicely to the thousands of clients. Then your chat program is just an XMPP client socket. Some of the Jabber servers even support HTTP connectivity for situations where a user's only access is via an http or http proxy server. I played around with Openfire a while back and was reasonably impresseed.
I'm fairly certain that iOS has sockets, and that it's allowed by Apple. I only know via second hand from folks that have worked on iOS products. You probably shouldn't use the push notification service for anything more than notifications to wake up your app that there is something it needs to do.
Hope this helps.
I wanted to add a voice chat feature to my business app. I have been trying hard to find anything useful but there is not much help regarding this. Could anyone plz point me to something concrete??
PS: The skype app makes use of this feature.
This is a lot of work as there is no "built in" sdk features or third party off the self components that will help you do it without a lot of work on your end.
Your options (as far as I know) are:
Build your own solution.
Look for a third party solution.
Look for a open source solution.
Voice "chat" could be one of many things like:
using the voice features of a cellular network to a conference call.
using the voice features of a cellular network with a PBX server that supports conference calls.
using a VOIP solution using a SIP stack with a SIP server
using a XMPP Jingle solution (I believe the google voice service uses this)
using your own SIP setup solution
custom solution
None of these options are easy.
Open Source SIP implementations that have iphone ports (that I know of):
reSIProcate
pjsip
Update:
SIP & Jingle both use RTP for the actual transport protocol between the parties. RTP is a UDP point-to-point protocol. The ports which form a session are negotiated using other protocols such as RTSP (using SDP in the setup method) and SIP. RTP and RTCP typically use unprivileged UDP ports (1024 to 65535).
For easy Server / Client setup check Jingle Nodes in combination with SIP Communicator which is a Desktop application. But as being opensource I presume you can reuse a lot of the code to make it mobile. Specially for Android. Check this draft of a Jingle Nodes Setup Guide
I've understood that Google Wave is built around the XMPP platform, as such I was thinking that it should be possible to access it with a jabber client like ichat or google talk. The advantage is that it's a lot faster to answer or read specific waves then going through a javascript jit in a browser.
Now you can add the xmpplite bot http://wave-xmpp.appspot.com/public/xmpplite.htm
but that is gwave -> xmpp only. It would be nice if one could also post to the wave with a jabber or e-mail client. Does anyone know a bot or a method of doing so?
The wave federation protocol is based on XMPP, but XMPP/BOSH isn't used for client-server communication, so it's not possible directly yet. However, since Google App Engine's XMPP service is bidirectional, there really isn't anything stopping the development of a robot which can be gwave <-> xmpp.