I am new to backend programming but would like to try and put together the backend of an app I am building. I essentially am looking to implement an observer type programming pattern, just between the server and ios app. For instance two different app users may subscribe to different things on the node.js server and would get different json sent to the swift of the app to use. I am unsure however how to go about trying to subscribe a user to the node.js using swift, and then essentially setting a listener for the json response as they come in. I would appreciate any help on this sort of server programming pattern type work if anyone has any references or thoughts.
Well, nodejs has the Event Emitter, that can be an implementation of observer pattern.
In your case, you can use a special Event Emitter based class, the Net module, that is a event emitter to handle tcp connections. As TCP connections are bidirectional by default, you can handle events in both sides using it.
So, you could handle the calls from the swift app (or other languages). It's just open the socket with server and send/receive data.
Related
I want to understand how can I integrate VoIP for my WEB app which in my case would be a Rails app.
What I wan't to achieve is sending socket events to the front-end for each call state:
call ringing
call started
call ended
The implementation is already done but I'm not convinced if is the right architecture and the informations I found until now over the internet are poor.
I don't think that makes sense to explain how is currently done (but if needed I can provide), but starting from ruby-asterisk gem which can be used to retrieve data about an extension number what would be the correct architecture in order to retrieve continuously events from call states and send them as socket events to the WEB?
How can you determine if the call is ended?
On the overall implementation, do you see any use of redis for saving previous states of a call and then to determine the new states?
Main issue is : asterisk is PBX
Again: it is small office PBX, not all-in-one platform with API.
So correct architecture for high load is centralized hi-perfomance socket server, which support auth, response on your api calls(if any), event notification etc etc. After that you have use AMI+ dialplan to notify you server about actions on PBX.
You web app should connect to thoose server, not directly to asterisk. Only ONE connection to asterisk recommended for peformance considerations.
If you have low load - doesn't matter what you do, it likly will work ok.
Asterisk not support redis, so use of that unlikly. Use CDRs for end event.
So I am working on a project where my iOS application acts as a server and receives connections from clients that send location data. My application reads this data from a socket and either updates the location of the clients on a MKMapView or creates a new one if it is a new connection.
I have my code completely unit tested so I feel some what confident about it. However, I am trying to write an acceptance test that will start my app and have a client connect to the socket, send some data and see if my app adds an MKAnnotation to the map view. Now I have had a little bit of experience with UI Automation but my issue is how can I write this networking code.
Here is what I need the test to do:
1.) Go to view controller where this networking code is happening (Easy enough with UI Automation)
2.) Once the view controller is loaded the server will start on port 2500 (Easy enough)
3.) Have a client connect to the server and send a message (This is what I don't know how to accomplish)
4.) Assert that the MKMapView has an annotation with the information I sent (Easy with UI Automation)
I know there is nothing native to javascript that will allow me to work directly with sockets, but could I use a library that uses web sockets? Other than that option I have not been able to find any resources online to solve testing a problem like this. I am open to any suggestions since I really don't know how to tackle this problem. I am sure there must be some way to test this. Thank you in advance and I am eagerly awaiting any suggetions!!
I want to make a chat app using Django in iOS. The server-side socket communication method that I've chosen is django-socketio because it integrates well with django. So my problem is selecting a way to implement the client side on iOS. All the django-socketio client examples are in javascript e.g-
To subscribe to a channel client-side in JavaScript use the socket.subscribe method:
var socket = new io.Socket();
socket.connect();
socket.on('connect', function()
{
socket.subscribe('my channel');
});
I want to know how to implement such a code in my iOS client, as in how to implement the "subscribe()" channel function from it, and how to implement interactivity from iOS to the various other events defined by the django-socketio server like:
#on_connect
def my_message_handler(request, socket, context):
...
and #on_message, #on_subscribe, etc.
I'm currently trying to use NSStream and CFStream as shown here, but it's proving difficult for me to convert it in a way to make it talk with django-socketio server.
(Note: for all those who saw the last "here" link, yea I did go the way of using twisted first instead of django-socketio, but it doesn't have any well-defined concrete method of integration with django (Yes, I tried searching it everywhere). Maybe it will be my next question here.
https://github.com/pkyeck/socket.IO-objc
PS: Now it doesn't support socketio protocol 1.0, neither django-socketio.
Wanted to build a chat like application(i.e bidirectional message passing to multiple connected clients). Looked at the Faye gem but it opens a new port apart from port 80.
The big problem is that if the client is behind firewall all access to other ports except 80 are restricted and not all the hosting sites provide the support.
The ActionController::Live component does not have any mechanism to register the clients so that the message can not be passed to the registered clients on a specific event occurance.
Looking for a solution where the alive clients are stored in a collection(array or somthing like that) and when any of the alive client sends a message then the collection can be iterated and the messages can be written on it. All of these must happen only through port 80.
Good question - having implemented something similar, let me explain how it works:
Connections
A "live" web application is not really "live" at all - it's just got a persistent request; meaning it still works exactly the same as a "normal" Rails app, except clients don't close the connection (hence why you're interested in opening another port)
The way you handle the request is where the magic happens. This is as much to do with the client-side, as it is with Rails (server-side)
Clients
When you connect to a "chat" application, your browser is opening a live connection with the server. This will typically be done with either server sent events (Ajax long polling), or web sockets
The way this works is to open the connection using the normal Rails ActionDispatch middleware, and then allow you to connect
If you've played with ActionController::Live functionality, you'll find that it's not a typical controller-action. It's actually a separate technology (like resque or Redis) which you call from another controller action. This gives room to do cool things with
Server
The way you'd handle something like this is to separate the "live" functionality and the "normal" Rails app. It's one of the current down-falls of Rails - in that it's probably better to implement something like nodeJS with socket.io to handle the live data (with an endpoint like chat.yourapp.com), whilst using Rails to handle authentication & authorization
From a server perspective, its job is to handle incoming & outgoing requests -- not to handle persistent connections. So I guess you may want to look at ways you could "outsource" the websocket connectivity. Admittedly, my experience is slightly thin in this area, so you may do well searching the net
Solutions
We've had a lot of success using a third-party system called Pusher
This is a web socket system which allows you to open a persistent connection as a client, and integrates with Rails in a similar way to Redis (you can push to it)
This means you can host the "chat" application with Rails (http://yourapp.com/chat), send the messages to your Rails app (http://yourapp.com/chat/send), and handle the incoming chats from pusher (or similar)
Maybe you want to use my open source comet web server (https://github.com/TorstenRobitzki/Sioux). There is a ruby web chat example. I use this to implement an interactive role playing map with rails (http://dungeonpilot.com).
I am to build a web application which will accept different events from external sources and present them quickly to the user for further actions. I want to use Ruby on Rails for the web application. This project is a internal development project. I would prefer simple and easy to use solutions for rapid development over high reliable and complex systems.
What it should do
The user has the web application opened in his browser. Now an phone call comes is. The phone call is registered by a PBX monitoring daemon. In this case via the Asterisk Manager Interface. The daemon sends the available information (remote extension, local extension, call direction, channel status, start time, end time) somehow to the web application. Next the user receives a notified about the phone call event. The user now can work with this. For example by entering a summary or by matching the call to a customer profile.
The duration from the first event on the PBX (e.g. the creation of a new channel) to the popup notification in the browser should be short. Given a fast network I would like to be within two seconds. The single pieces of information about an event are created asynchronously. The local extension may be supplied separate from the remote extension. The user can enter a summary before the call has ended. The end time, new status etc. will show up on the interface as soon as one party has hung up.
The PBX monitor is just one data source. There will be more monitors like email or a request via a web form. The monitoring daemons will not necessarily run on the same host as the database or web server. I do not image the application will serve thousands of logged in users or concurrent requests soon. But from the design 200 users with maybe about the same number of events per minute should not be a scalability issue.
How should I do?
I am interested to know how you would design such an application. What technologies would you suggest? How do the daemons communicate their information? When and by whom is the data about an event stored into the main database? How does the user get notified? Should the browser receive a complete dataset on behalf of a daemon or just a short note that new data is available? Which JS library to use and how to create the necessary code on the server side?
On my research I came across a lot of possibilities: Message brokers, queue services, some rails background task solutions, HTTP Push services, XMPP and so on. Some products I am going to look into: ActiveMQ, Starling and Workling, Juggernaut and Bosh.
Maybe I am aiming too hight? If there is a simpler or easier way, like just using the XML or JSON interface of Rails, I would like to read this even more.
I hope the text is not too long :)
Thanks.
If you want to skip Java and Flash, perhaps it makes sense to use a technology in the Comet family to do the push from the server to the browser?
http://en.wikipedia.org/wiki/Comet_%28programming%29
For the sake of simplicity, for notifications from daemons to the Web browser, I'd leave Rails in the middle, create a RESTful interface to that Rails application, and have all of the daemons report to it. Then in your daemons you can do something as simple as use curl or libcurl to post the notifications. The Rails app would then be responsible for collecting the incoming notifications from the various sources and reporting them to the browser, either via JavaScript using a Comet solution or via some kind of fatter client implemented using Flash or Java.
You could approach this a number of ways but my only comment would be: Push, don't pull. For low latency it's not only quicker it's more efficient, as your server now doesn't have to handle n*clients once a second polling the db/queue. ActiveMQ is OK, but Starling will probably serve you better if you're not looking for insane levels of persistence.
You'll almost certainly end up using Flash on the client side (Juggernaut uses it last time I checked) or Java. This may be an issue for your clients (if they don't have Flash/Java installed) but for most people it's not an issue; still, a fallback mechanism onto a pull notification system might be prudent to implement.
Perhaps http://goldfishserver.com might be of some use to you. It provides a simple API to allow push notifications to your web pages. In short, when your data updates, send it (some payload data) to the Goldfish servers and your client browsers will be notified, with the same data.
Disclaimer: I am a developer working on goldfish.
The problem
There is an event - either external (or perhaps internally within your app).
Users should be notified.
One solution
I am myself facing this problem. I haven't solved it yet, but this is how I intend to do it. It may help you too:
(A) The app must learn about the event (via an exposed end point)
Expose an end point by which you app can be notified about external events.
When the end point is hit (and after authentication then users need to be notified).
(B) Notification
You can notify the user directly by changing the DOM on the current web page they are on.
You can notify users by using the Push API (but you need to make sure your browsers can target that).
All of these notification features should be able to be handled via Action Cable: (i) either by updating the DOM to notify you when a phone call comes in, or (ii) via a push notification that pops up in your browser.
Summary: use Action Cable.
(Also: why use an external service like Pusher, when you have ActionCable at your disposal? Some people say scalability, and infrastructure management. But I do not know enough to comment on these issues. )