Re:Re:Re: ??:Re: Puzzled at "storeKeyPublic" and "storeKeyText"

Thanks, Henrik pal!

Your reply is a great help to me. :-)

Best regards,
George Ma

----- Original Message -----
From: Henrik Nordstrom
To: maer727@sohu.com
Cc: squid-dev@squid-cache.org
Subject: Re:Re: ??:Re: Puzzled at "storeKeyPublic" and "storeKeyText"
Sent: Wed Apr 17 15:51:19 CST 2002

> On Wednesday 17 April 2002 08:52, maer727@sohu.com wrote:
>
> > Your reply helps a lot and gives me a light. :-)
> > Now I want to take several days to make myself familiar
> > with the basic data structures (for example, StoreClient)
> > and basic functions (for example, clientProcessRequest).
>
> Ignore the internal StoreClient data structures. This is not anything
> important for understanding Squid. Instead concentrate on how to use
> a StoreClient by reading the code in client_side.c. You only need to
> know what a StoreClient represents, not the details of how it is
> composed. This also applies to most other structures. The details of
> the structures is only needed when working on that specific piece of
> code, and then the tools shown before will give you the needed
> information when you need it..
>
> Understanding clientProcessRequest and it's related code threads in
> client_side.c is a very important step. If you manage to understand
> these then you have understood most of the coding style in Squid. But
> unfortunately client_side.c is a bit of a messy place to start.
>
> I would probably recommend starting by reading a server side
> protocol, such as http.c. Starting with httpStart(). This gets called
> with a fwdState containing mainly three important pieces of
> information
>
> a) A filedescriptor that is connected to the HTTP server
> b) A request_t, containing the request to send.
> c) The StoreEntry to where the reply should be sent internally
> within Squid.
>
> The overall style in coding is mostly the same, but not by far as
> messy as client_side.c.
>
> > Then I will read the rest details, maybe the MD5 algorithm etc.
>
> Same thing for MD5. You do not need to know the mathematics of MD5,
> only what it does. MD5 calculates a 16 bytes fixed size key from
> arbitrary amount of input data. The same input data will always
> result in the same 16 bytes, and the likelyhood that two different
> combinations of input data ends up as the same 16 output bytes is
> extremely low.
>
> Regards
> Henrik
Received on Wed Apr 17 2002 - 07:57:13 MDT