I am quite new to google ChromeCast, so please feel free to point out anything that just doesn't make sense.
Basically I am working on a sender application that ChromeCast can fetch videos from. For scaling reason, the sender application runs behind an AWS ELB. The problem is that the Chromecast client has to work with the same sender application once the video stream starts, but the AWS ELB randomly allocates requests from the chromecast to different sender applications.
Could someone advise a way to configure the AWS ELB to ensure one chromecast client always be allocated to the same sender application once the video stream starts? Thanks.
I actually figured it out myself. In this "AWS ELB <--> Sender Application Instances"
structure, I managed to change the Sender application to store all the generated files in AWS Redis. Then, other sender application instances can also have access to those generated files, as the AWS REDIS is an unique instance accessible to all sender application instances.
All these changes are transparent to ChromeCast. Problem solved.
Related
I have a question about how to load balance web sockets with AWS elastic load balancer.
I have 2 EC2 instances behind AWS elastic load balancer.
When any user login, the user session will be established with one of the server, say EC2 instance1. Now, all the requests from the same user will be routed to EC2 instance1.
Now, I have a different stateless request coming from a different system. This request will have userId in it. This request might end up going to a EC2 instance2. We are supposed to send a notification to the user based on the userId in the request.
Now,
1) Assume, the user session is with the EC2 instance1, but the notification is originating from the EC2 instance2.
I am not sure how to notify the user browser in this case.
2) Is there any limitation on the websocket connection like 64K and how to overcome with multiple servers, since user is coming thru Load balancer.
Thanks
You will need something else to notify the browser's websocket's server end about the event coming from the other system. There are a couple of publish-subscribe based solution which might help, but without knowing more details it is a bit hard to figure out which solution fits the best. Redis is generally a good answer, and Elasticache supports it.
I found this regarding to AWS ELB's limits:
http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elastic_load_balancer
But none of them seems to be related to your question.
Websocket requests start with HTTP communication before handing over to websockets. In theory if you could include a cookie in that initial HTTP request then the sticky session features of ELB would allow you to direct websockets to specific EC2 instances. However, your websocket client may not support this.
A preferred solution would be to make your EC2 instances stateless. Store the websocket session data in AWS Elasticache (Either Redis or Memcached) and then incoming connections will be able to access the session regardless of which EC2 instance is used.
The advantage of this solution is that you remove the dependency on individual EC2 instances and your application will scale and handle failures better.
If the ELB has too many incoming connections, then it should scale automatically. Although I can't find a reference for that. ELB's are relatively slow to scale - minutes rather than seconds, if you are expecting surges in traffic then AWS can "pre-warm" more ELB resource for you. This is done via support requests.
Also, factor in the ELB connection time out. By default this is 60 seconds, it can be increased via the AWS console or API. Your application needs to send at least 1 byte of traffic before the timeout or the ELB will drop the connection.
Recently had to hook up crossbar.io websockets with ALB. Basically there are two things to consider. 1) You need to set stickiness to 1 day on the target group attributes. 2) You either need something on the same port that returns static webpage if connection is not upgraded, or a separate port serving a static webpage with a custom health check specifying that port on the target group. Go for a ALB over ELB, ALB's have support for ws:// and wss://, they only lack the health check over websockets.
Ok, so I have an elastic beanstalk application with a scalable web tier, served behind an ELB. Long story short, I need to be able to subscribe a specific instance within my web tier to an SNS topic. Is it safe for me to use a standard method to get the instance ip address (as detailed in python here How can I get the IP address of eth0 in Python?) and then simply subscribe to an SNS topic using that ip as an http subscriber?
Why? Good question...
My datamodel is made up of lots of objects many of which can have an attached set of users which may want to be able to observe those objects. This web tier in my application is responsible for handling the socket interface (using socket.io) for client applications.
When a user is created in the system, so too is an SNS topic for the user, allowing notifications to be pushed to that user when an object it is interested in changes. The way I am planning to set this up, a client application will connect to EB via socket.io at which point the server instance it connected to will subscribe to that user's SNS topic. Then when an interesting object changes, notifications will be posted to the associated user's topics, thus notifying the server instance that the client application has an open connection to, which can then send a message down the socket.
I believe it is important that the specific instance is subscribed rather than the web tier's external CNAME or ip, as the client application is connected to a specific instance and so only that instance can send messages over it's socket. Subscribing the load balancer would be no good as the notification may be delivered to an instance that the user is not connected to.
I believe the question at the top is all I need, but I'm open to creative solutions if my reasoning seems flawed??
Just incase anyone gets stuck down this same rabbit hole... The solution was to use Redis pub/sub rather than SNS and SQS.
My current set up has AWS Couldwatch alarm triggering the sending of an email notification when, eg. CPU usage is below x% for n minutes. This is easy enough to set up through the AWS Management Console. However, under this arrangement, I then need to remote login into the instance and restart my failed application manually. I'd like to automate this with the same Cloudwatch alarm event, instead triggering the running of a script (on the same EC2 instance as my application) which would then restart my application. How to do this?
If there is a way to catch the Cloudwatch alarm event from within the instance running the application, then this might be an easy way to proceed, but I can't find out how to do that.
There is a similar question posted here (How to restart EC2 instance from CloudWatch alarm). In my case however, I don't think that Auto Scaling is a viable option; because of licensing restrictions on some other software running on the instance.
I'm running a windows based EC2 instance.
Thanks,
Yug
An AWS CloudWatch alarm can be used to trigger:
An auto scaling policy (eg add/remove instances in an auto scaling group)
Stop / Terminate an EC2 instance
Send a notification via Amazon Simple Notification Service (SNS)
SNS can then send the notification to subscribers in various formats:
Send an SMS (USA only)
Push a message to an HTTP/S endpoint (eg an application you have written)
Push a message to an Amazon Simple Queue Service (SQS)
Send a notification to mobile device (eg Android, iPhone)
Based on your scenario, the HTTP or SQS notifications could be used, but you would have to write a program to respond to the notifications. However, you would only be using a proxy for your app's health (eg CPU Utilization) rather than actually monitoring the health of your app.
You can send a Custom Metric from an application to CloudWatch and then configure an alarm to trigger based on this Custom Metric. But, if you're going to all that trouble, then the code that detects the problem should probably fix it directly, rather than going via CloudWatch.
does anyone know if its possible to host the receiver app for chromecast in a remote host, such as heroku? Is it only possible to find my chromecast device if its in the same wi-fi network?
You've got two separate questions here.
1) Yes, the receiver app can be hosted anywhere, and the vast majority of them are on a remote host rather than served locally. When you register your app with the Chromecast SDK console, you will have to submit, with the appID, the URL where the receiver app is located. Keep in mind that if your app is 'published' (available to all rather than just to those Chromecasts you whitelist), then your host much be https:// enabled, whether it's local or remote.
2) I think you're asking whether or not a sender app can find a device that's not on the same wi-fi network? Generally, no ... but at Google I/O this summer they did discuss a feature that would allow people not on the network but close enough to the Chromecast (i.e. in the same room) to communicate.
If I'm misunderstanding question two, please clarify.
I've downloaded sender and receiver applications from GITHUB and try to run the same on my server. I've followed all the guidelines that are mentioned over there and on the developers site. But still i am not getting any result. I want to know that whether a receiver application is specific for the sender application or we can use any receiver application for my sender application provided that we use our application id that we got after publishing it on the Google Developers Console ?
If its not general.. can anyone provide a sender application and corresponding receiver application sample so that I can learn a bit. Thanks in advance.
The only "sandboxing" of receivers happens in the Chromecast SDK Console -- when you publish an app there and it's assigned an appID, it will be available to any sender that calls that appID (or, if it's an unpublished app, any sender that you've whitelisted to call that appID). You'll want to check all the settings in the SDK console; if the app is unpublished, make sure you've put the right serial number in for your devices to whitelist them and make sure that your device settings have the 'send serial number' option checked so they know they're whitelisted. But there is nothing right now, by default, in the receiver code that could stop other senders from connecting.
This doesn't mean, of course, that you couldn't write an authorization layer into your receiver app to prevent non-authorized senders from connecting.