 The basic design of content delivery networks is such that it is meant to be scalable for large number of users the CDN can expand and for decreasing number of customers as The need requires as the requirements grow or shrink correspondingly the users pay what they use but in certain situations there is a spontaneous or Certain change in demand It's known as an upsurge This is called flash crowd in terms of Usage it was a term that was coined back in 70s So we are going to look at how Content delivery networks through their internal dynamism respond to such flash crowds We'll talk about some interesting case studies From the recent internet experience. We'll identify the challenges some potential Solutions the alternatives and then we'll focus on flash crowd elevation network based architecture What are flash crowds? Flash crowds actually are the spontaneous gathering or Collection of users which come close to an object of interest This is triggered in such a short manner and goes away Very quickly as well But this upsurge has to be catered for the users start Perceiving poor quality of service and from the network centric perspective The servers are unable to handle a very large number of requests There are some examples from history For example when the red hat Linux image distribution was announced The website offering that got overwhelmed similarly the Examples are play along TV show. It was streamed back in 2000 and again It got bogged down with an increasing certain interest of users who visited the site and brought it down the Chilean presidential elections of 1999 the live eclipse the solar eclipse or I guess it was lunar eclipse back in 2005 and the The CNN broadcasting of the images of 911 where the Twin Towers were brought down It was live broadcast. So these are the examples where the flash crowds Are created on the fly? There is something known as slash.net effect as well Slash.net is a very well known website that Discusses or brings into notice some emerging technology trends some new advancements or some celebrities In the kind of hall of fame manner. So this slash.net Website when it refers to another web server or a website that website Gets so much of attention that it cannot handle Whereas slash.net has a pretty robust infrastructure So the demand has to be met it cannot simply be denied There are certain challenges for instance how to organize the temporary overlay of The servers these are simply known as the surrogate servers which are Proxying on behalf of the original web server, but it has to be very quick efficient There should be a very marvelous cooperation mechanism amongst these surrogate servers and As soon as the flash crowd goes away it disperses then The situation has to get back to normal and all these Overprovisioned resources have to be relieved. So how can it be done in a very small overhead and minimum possible time? then Even the fundamental question arises how to detect flash crowds and how to detect if it has now departed for that some kind of prediction mechanism or interpolation or probably Extra-polation has to be taken into consideration and Last but not the least the clients which visit the website, which is a flash crowded or Slashed for that matter how to make it very Seamless and transparent for the clients Let's look at some Possible ways which are very intuitive alternatives. The first one is Server layer solution that is increase the number of servers. So the surrogates or the active proxies Takeover and Then there are some backups known as delegates So this server based solution is of course a server intensive it is not taking any support from smart algorithmic usage or Distribution of the content which is being accessed There's an example of paper known as dot slash what happens is some kind of Mutual mutually benefiting community Takes on the task of supporting each other in the wake of seeing flash crowd so it means that The web server community joins hands together There there's a catch though For instance to be exact if there is Flash cloud a flash crowd that flash crowd has to be now Managed principally through redirection this redirection Has to take place at the origin server. So it means the origin server Eventually is the bottleneck. It is simply not a purely decentralized approach Then we have the intermediate layer solution when we call it intermediate. It means farther from the server closer to the Clients or the users. So the first thing that can be done is identify how and Where the content is best replicated and replaced for that multi-level caching is one good idea Then there is a research paper known as backslash Here some free mirrored Proxies are used which do not replicate hundred percent content to be shared with the Users but replicate part of it and this has to be done very smartly so this offloads the central centralized approach by distributing it across the Caches of some servers across the CDN community The third and the lowest or the closest to the client is the client layer solution what happens is Through the mediation of the original web server, which is suffering from flash crowd Some client cooperation is initiated and the clients form a peer-to-peer overlay network so the clients are redirected to Those clients which have just recently downloaded the object. It's a very typical bit tolerant kind of working Visually you can see starting from the left the server based approach the server layer the clients are banking on the Surrogate and delegate servers Then the intermediate layer is where the Clients are not actually burdening the server as such rather some kind of caching mechanism and Content and object replacement is taking place and then the most efficient and Extremely distributed is the client layer based approach where a pure peer-to-peer architecture Offloads the burden totally from the shoulders of the central server now the architecture which has been proposed in Raj Kumar Bhaiya is for the Elevation of the flash flash clouds the Afghan architecture here as you can see the clients are aware of The presence of certain cashier Under normal circumstances these cashier proxies Which can be approached by resolving using DNS Name resolution capability these clients are just accessing the coin content directly from the origin server But when the flash crowd starts to build and it does not build in in in a Jiffy or in a very short Time rather it might take a while you say 10 to 15 minutes so for the flash crowd to appear now the Clients would refer to the DNS because they would start getting relatively slow service now the origin server takes into account the Response that it is giving to the clients involves the clients to avail the DNS service for accessing the cashier proxies and Under a fully loaded Situation a very large number rather all the cashier proxies are now being used to Relieve the burden of the origin server in order to now comprehend how this Architecture works where the flash crowd are elevated through the involvement of proxies The entire process can be understood through the interaction between the server the initial set of proxies and the additional proxies which are Required as the flash crowd becomes intense So the server starts off as a normal server when it detects that there's a flash crowd it starts probing the proxies which respond to the server and Updates the presence of these proxies in its DNS records and then switches the proxies the proxies are now Delegated the task to act as surrogates and the start functioning But over time the proxies also get overburdened because of increasing load the server now checks the logs which are collected from the surrogates and probes for further proxies the Proxies which are the additional proxies which were not part of the initial set Respond to the server the DNS records are updated and then the proxies are switched to act as surrogates this process keeps on repeating itself For as long as the flash crowd keeps growing and when it starts going away or Departing correspondingly the number of proxies handling the situation are reduced in number This is again taken from content delivery networks by Raj Kumar, Bhaiya