Here is a small architecture with 3 Front Ends (click to zoom):
Front End A: 10.0.0.1
Front End B: 10.0.0.2
Front End C: 10.0.0.3
Each Front Ends will respond to http://intranet.fabrikam.com because their
IIS Host Headers are configured to “intranet.fabrikam.com”, but if you use this
URL its the “Load Balancer” which is going to reply.
So, How can you access http://intranet.fabrikam.com on Front End A
?
You have to send the HTTP Request to the Front End A’s IP Address
(10.0.0.1) using “intranet.fabrikam.com” as the host value in the
HTTP Request.
Here is the HTTP Request you must build to access http://intranet.fabrika.com :
GET / HTTP/1.1
Accept: application/x-ms-application, */*
Accept-Language: en,fr-BE;q=0.5
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729
Accept-Encoding: gzip, deflate
Host: intranet.fabrikam.com
Connection: Keep-Alive
Then you have to send it to Front End A’s IP Address (10.0.0.1) How
to send that request to that IP Address ? There are many ways to do that:
- Using System.Net.Sockets.Socket
- Using WebClient or WebRequest (method A)
- Using WebClient or WebRequest (method B)
There is a major drawback with this method, you’ll have to handle
authentication manually (easy with Basic Authentication, pretty hard with Ntlm
or Kerberos)
Second Method (Using WebClient or WebRequest (method A)):
1 2 3 4 5 6 7 8 9 10 11 12 13 |
string strHttpRequest = String.Concat("GET / HTTP/1.1rn", "Accept: application/x-ms-application, */*rn", "Accept-Language: en,fr-BE;q=0.5rn", "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729rn", "Accept-Encoding: gzip, deflatern", "Host: intranet.fabrikam.comrn", "Connection: Keep-Alivernrn"); //Create a IPv4 TCP Socket Socket socketClient = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); //Connect to the Front End A's IP address on HTTP Port (80) socketClient.Connect(IPAddress.Parse("10.0.0.1"), 80); //Send the Http Request socketClient.Send(Encoding.Default.GetBytes(strHttpRequest)); StringBuilder sbHttpResponse = new StringBuilder(); byte[] bReceiveBuffer = new byte[4096]; int iReceivedBytes = 0; //Process the Http Response while ((iReceivedBytes = socketClient.Receive(bReceiveBuffer)) > 0) sbHttpResponse.Append(Encoding.Default.GetString(bReceiveBuffer, 0, iReceivedBytes)); //Output the Http Response Console.WriteLine(sbHttpResponse.ToString()); |
Apparently this method will only work with .NET FrameWork 4.0, actually it
doesn't (.NET 3.5) because you cannot alter the “Host” header value(https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=384456)
Additionally, there is a way (hack) to access the internal collection of
headers to bypass the validation:
http://blog.scoftware.com/post/2009/07/28/SOLUTION-HttpWebRequest-raw-headers.aspx
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
//Create a HttpWebRequest to Front End A's IP Address HttpWebRequest myHttpWebRequest = (HttpWebRequest)HttpWebRequest.Create("http://10.0.0.1"); //Modify Host header to reach intranet.fabrikam.com myHttpWebRequest.Headers[HttpRequestHeader.Host] = "intranet.fabrikam.com"; //Process Response HttpWebResponse myHttpWebResponse = (HttpWebResponse)myHttpWebRequest.GetResponse(); Stream streamResponse = myHttpWebResponse.GetResponseStream(); StreamReader streamReader = new StreamReader(streamResponse); string strHttpResponse = streamReader.ReadToEnd(); //Output Response Console.WriteLine(strHttpResponse); streamResponse.Close(); streamReader.Close(); myHttpWebResponse.Close(); |
Third Method (Using WebClient or WebRequest (method
B)):
Using the Proxy property of WebClient you can target http://intranet.fabrikam.com and connect to
10.0.0.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
//Create a WebClient WebClient webClient = new WebClient(); //You can eventulay set a Username / Password as NetworkCredentials webClient.Credentials = new NetworkCredential("username", "password"); //The Front End A's IP Address to connect to webClient.Proxy = new WebProxy("10.0.0.1"); //Will set the correct Host Header Stream streamResponse = webClient.OpenRead("http://intranet.fabrikam.com"); //Process the HttpResponse StreamReader streamReader = new StreamReader(streamResponse); string strHttpResponse = streamReader.ReadToEnd(); //Output the HttpResponse Console.WriteLine(strHttpResponse); streamResponse.Close(); webClient.Dispose(); |
That’s all for today !
Le pool Small buffers contient 10
buffers (10 libres / 10 buffers en permanence).
On reçoit 5 paquets, l’IOS alloue 5
buffers « 5 hits ».
On reçoit 4 paquets supplémentaires
(hits+=4) « 9 hits ». La demande de 4 buffers provoque « 4 misses » car les 4
buffers font tomber le compteur de buffers libres en dessous du minimum de ce
pool « 1 in free list / 5 min »
Vu que le nombre de buffers libre est
inférieur au minimum, l’IOS alloue 4 buffers supplémentaires pour le satisfaire
« 4 created ».
On reçoit 6 paquets supplémentaires. Il
n’y a de place que pour 5 de ces paquets (hits+5) « 14 hits ». Le paquet
n’ayant pas eu de buffer est perdu « 1 failure ». La demande de 6 buffers a
provoqué (4+6 misses) « 10 misses » car le minimum n’est plus respecté.
Certains buffers qui étaient utilisés
sont libérés « 12 in free list »
Le nombre de buffers libre est
supérieur au maximum autorisé. L’IOS supprime l’excédant de buffers « 4 trims
».
In the last figure, there are only
small non-contiguous freed blocks: Now, if a process wants to allocate a larger
memory area, it will not be able to do it and it’ll have a “MALLOCFAIL” error.
The Chunk Manager will try to avoid this kind of situation by allocating the
memory to processes cleverly. The Chunk Manager is responsible of the Chunks
Allocation. A Chunk contains a finished number of memory blocks of equal size.
If we use every memory blocks of a Chunk, the Chunk Manager will allocate a new
memory area (Sibling). If no more blocks of this “Sibling” are used, it is
freed “Freed/Trimmed”. A process now has a larger allocated memory area split
into smaller memory blocks. When a process frees a memory block, it does in its
Chunk. There is no more fragmentation due to different processes freeing
memory. 
In the next post: The
Chunk Manager!
1. The Scheduler
starts with Critical Priority Stack and runs then removes all processes within.
2. If the Critical Stack is empty, the Scheduler moves on to High Priority
Stack and runs then removes the first process. Once the first process was run,
the scheduler checks that the Critical Stack is still empty. If it’s not, the
Scheduler runs then removes all processes within it. The Scheduler moves on to
the next High Priority Process. After each High Priority Process, the Scheduler
checks if there is a higher priority process (Critical). If so, it runs then
removes it. 3. If both Critical Stack and High Priority Stack are empty, the
Scheduler moves on to Medium Priority Stack. Between each Medium Priority
Process, the scheduler checks if there are any High Priority Processes to run.
If there are, it runs the first one and removes it, then checks if there are
any Critical Processes to run and runs then removes all of them. When the
Critical stack is empty, the scheduler moves on to the next High Priority
Process, and so on … 4. If the Critical/High/Medium Priority stacks are empty,
the scheduler moves on to the Low Priority Stack. (If we are coming from the
Medium Priority Stack, we do not move on to the Low Priority Stack. At the end
of the Medium Priority Stack, we move on to Critical Priority Stack. When we’ve
executed this step 15 times, we finally move to Low Priority Stack). Between
each Low Priority Process, the scheduler checks if there are any Medium
Priority Process to run. If there are, it runs and removes each Medium Priority
Process but between each of them the scheduler checks if there are any High
Priority Process to run. If there are, it runs then removes it, but between
every High Priority Process, it checks if there are any Critical processes to
run, to run and remove them all. 5. It goes back to step 1. If a process
forgets to release the CPU within 4sec, no worry! The WatchDog Timer will kill
it! The WatchDog Timer is refreshed by an Interrupt (every 4msec by the System
Timer). The Incoming Packet Notification is also done using an Interrupt. So
the IOS can instantaneously process the incoming packet. I will talk about the
Packet Switching Methods soon. Next Post: IOS uses of the Memory
There are 4 process
priorities (one queue FIFO/priority):
Dans ce dernier
exemple, il n’y a que des petits blocs non contigus libérés, résultat : Si un
processus désire allouer une zone mémoire plus importante, il ne pourra pas le
faire et nous aurons un « MALLOCFAIL ». Le Chunk Manager va permettre de régler
ces soucis en allouant plus intelligemment la mémoire aux processus. Le Chunk
Manager est responsable de l’allocation de Chunk. Un Chunk contient un nombre
de blocs finis de taille égale. Si on utilise tous les blocs présents dans un
Chunk, le Chunk Manager alloue un nouvel espace (Sibling). Si plus aucun des
blocs de ce « Sibling » n’est utilisé, il est libéré « Freed/Trimmed ». Un
processus se voit donc attribuer une plus grande zone mémoire découpée en plus
petits blocs. Lorsque le processus libère un bloc, il le fait dans son Chunk.
Il n’y a donc plus de fragmentation entre différents processus. 
Le post suivant
parlera du « chunk manager » de l’IOS.
1. Le scheduler
démarre avec le Critical Priority Stack et exécute tous les processus s’y
trouvant. 2. S’il n’y a plus rien dans Critical, le scheduler passe au High
Priority Stack et exécute le premier processus. Une fois le premier processus
exécuté, le scheduler vérifie la présence de processus dans la Critical Stack.
S’il y en a, le scheduler les exécute. Le scheduler peut donc passer au
processus suivant du High Priority Stack. Le scheduler vérifie après chaque
processus High Priority Stack la présence de processus de plus haut niveau pour
les exécuter. 3. S’il n’y a plus de processus Critical, ni de processus High,
le scheduler passe au Medium Priority Stack. Entre chaque processus du Medium
Priority Stack, le scheduler vérifie la présence de processus dans le High
Priority Stack. S’il y en a, il exécute le premier puis vérifie la présence de
processus dans le Critical Priority Stack et les exécute tous. Une fois le
Critical vide, il passe au High Priority suivant, etc … 4. S’il n’y a plus de
processus Critical, ni de processus High, ni de processus Medium, le scheduler
passe au Low Priority Stack. (A savoir que si l’on vient du Medium Priority
Stack on ne passe pas au Low Priority Stack. A la fin du Medium on passe au
Critical Priority Stack, lorsque cette étape a été réalisée 15 fois on passe
finalement au Low Priority Stack – Ca c’est du LOW). Entre chaque processus en
Low Priority le scheduler vérifie le Medium Stack et exécute les processus du
Medium Stack entre-lesquels le scheduler vérifie la présence de processus dans
le High Stack et les exécute tout en vérifiant entre chaque processus High la
présence de processus Critical pour les exécuter tous avant de passer au
suivant High. 5. On retourne à l’étape 1. Si un processus devient fou (>4sec
sur le CPU), pas de problèmes ! Le WatchDog Timer est là pour l’interrompre !
Le WatchDog Timer est exécuté via une interrupt (toutes les 4msec via le system
timer), donc plus prioritaire que n’importe quel processus. La notification
d’arrivée de paquet est aussi une interrupt. Ainsi l’IOS peut directement
traiter le paquet. Je reviendrai prochainement sur les méthodes existantes de
Switching de Paquets. Prochain post: l’organisation mémoire de l’IOS.
Il existe 4 priorités (une file
FIFO/priorité) de processus afin d’en favoriser certains par rapport à d’autres
:
