by
Adrian Lorentz , Principal IT officer (analyst-programmer) , A.N.P.
The client/server communication is made through a protocol. The server is the IIS, so remains to establish which is the protocol and the client.
The client is recognized by IIS through the protocol used for its requests, which contains in the protocol definition fields that allow client recognition.
If the protocol used is HTTP, for example, then the first line of the request message from a client to the IIS will include the HTTP method to be applied to the resource hosted on server, the identifier of that resource, and the protocol version in use … something like GET http://IIS_Server/Path_On_IIS_Server/Resource_Hosted.html HTTP/1.1; see RFC 2616/ User-Agent request-header field and HTTP Request Processing in IIS resources for more details on this matter.
If the protocol used is FTP, then the client is recognized from the stage of initiating the connection, through userName and userPassword given.
So on ... it is, mainly, a problem of protocol knowledge and IIS requests processing.
the same concept of any other service applies to Web Servers such as (IIS):
The combination of client public IP and his PORT number.
so every connected client to an IIS server have a unique IP/PORT combination, which allows the web server to communicate back the response to the right client/request.
1.
A request arrives at HTTP.sys.
2.
HTTP.sys determines if the request is valid. If the request is not valid, it sends a code for an invalid request back to the client.
3.
If the request is valid, HTTP.sys checks to see if the request is for static content (HTML) because static content can be served immediately.
4.
If the request is for dynamic content, HTTP.sys checks to see if the response is located in its kernel-mode cache.
5.
If the response is in the cache, HTTP.sys returns the response immediately.
6.
If the response is not cached, HTTP.sys determines the correct request queue, and places the request in that queue.
7.
If the queue has no worker processes assigned to it, HTTP.sys signals the WWW service to start one.
8.
The worker process pulls the request from the queue and processes the request, evaluating the URL to determine the type of request (ASP, ISAPI, or CGI).
9.
The worker process sends the response back to HTTP.sys.
10.
HTTP.sys sends the response back to the client and logs the request, if configured to do so