Categories
Uncategorized

AWS Resource Migration across account – Part 1 – EC2

There have been cases when one need to migrate there AWS account. The one very obvious reason is that you’re using AWS free tier services. And after an year, as the free tier is over, you may want to create a new AWS account.

But when you create a new AWS account, you need to recreate all of your AWS resources, like EC2, ELB, S3, RDS, Elasticsearch, etc.

Along with recreating all the resources you would need to retain all the data, tools, settings of your current AWS resources. For example, suppose you were running an EC2 machine for a website. You had installed various tools on that machine, like phpmyadmin, nodejs, nginx, python, gunicorn.

Now creating a new account and corresponding resources is Okay, but re-setting everything to current state is not very straight-forward.

But let me tell you, the resetting of everything is not actually very difficult.

This article of the AWS account migration series will focus on migration of EC2 resource on AWS.

Terminologies:

  • naws : New AWS account
  • oaws: Old AWS account

Steps to migrate EC2 from oaws to naws:

  1. Create an AMI for EC2 resource in oaws
  2. Edit Permission of above created AMI.
  3. Add naws account id in the step 2. This should share the above AMI with naws.
  4. Wait for few minutes. The sharing of AMI might take 5-15 minutes.
  5. Go to AMI list and select Shared AMIs. You should see above create AMI here. In case you don’t see it yet, pl wait for a while.
  6. Once you see the new AMI in naws, select that AMI and launch a new EC2 resource.
  7. Create New security group in naws, copying values from oaws.
  8. Attach above created security group to the new EC2 resource in naws.
  9. You should have a working EC2, a clone of EC2 in oaws. You might have to ssh into new EC2 resource and start your servers, in case they are not included in upstart script as the EC2 is recently launched and hence started.
Categories
ajax bidirectional chat chatting full-duplex http live live-users long-polling node.js persistent persistent-connection polling real-time response reverse-proxy socket socket.io tcp Uncategorized websocket websocket-handshake

Long Polling Vs Socket

There is no match, in the battle of Long Polling Vs Socket, Socket clearly wins.(As long as I’m the referee, for now).

Long Polling and Sockets are the two different, well known, ways to implement real time applications, like live users or chatting where you have to broadcast the changes instantaneously. This post is going to compare the two technologies for their use. You might feel that this post is being biased as I can’t make myself like Long Polling over Sockets. I will try to reason this biasness or more importantly the logical thinking why one should not prefer polling(short or long) over sockets.

Polling is a method where the client requests server like ajax, the difference is that it is set at timed interval which means every some second it requests the server for the response. It is also known as short polling. Long polling is another dirty trick with the same concept.

Long Polling is a method when the client makes ajax request to server but the server do not response instantaneously but instead it holds the response until there is some change in the database or else the request times out. (WTF, then what does it do with the persistent connection all the time before it times out). The trick here is that with long polling we are saving the number of unnecessary requests to the server which would been made for no change in data.

Socket is a method when the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response. The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port. Once the connection is established, communication switches to a bidirectional binary protocol that does not conform to the HTTP protocol. Once the connection is established, the client and server can send WebSocket data or text frames back and forth in full-duplex mode. The data is minimally framed, with a small header followed by payload.

Lets start.

First of all, Long Polling is an outdated method and Socket is the future. Long Polling was used as a trick for polling when sockets were not there.

This makes your client’s browser slow or might hang it up as at every interval there is a ajax request done. This also looks suspicious to the client(what is it that being requested from my browser, why my browser consumes so much memory).

This also increases server load, as there are requests at continuous intervals. It is like timed persistent connection because until the server generates response or else timeout, connection is kept alive and after the response received, another request for persistent connection is generated. So why not create it once and for all. For each request there is an overload of TCP connection handshake which is minimized to single handshake. As there are multiple requests so the overload of payload will also be there.

Long polling maintains a loop which constantly checks for change in database which only decides whether to response back to client. In Node.js, you can share the same memory for different socket connections, so that way they can access shared variables. So you don’t need to use database as exchange point in the middle (like with AJAX or Long Polling). You can store data in RAM, or even republish between sockets straight away.

With AJAX(Long polling) there is a higher chance of MITM as each request is new TCP connection and traversing through internet infrastructure. With WebSockets, once it’s connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, that requires more effort to probe data.

With long polling there is higher latency than sockets. Http is the stateless protocol, which means it forgets connection after the work is done, so there will be delay in response as it will have to make an all new request. But with socket, it reflects the change as soon as it detects.

Some nice links can be found hereherehere.

That’s it for today. You are most welcome to break the monotonicity of the fairness of socket over long polling.

Thanks Guys.