On Thu, Mar 13, 2014 at 5:44 PM, Alex Rousskov
wrote:
> On 03/13/2014 07:24 AM, Nikolai Gorchilov wrote:
>> On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov wrote:
>>> Just to make sure we are on the same page, here is a list of options I
>>> recall being discussed:
>>>
>>> 1. Using ICP reqnum field
On 03/13/2014 07:24 AM, Nikolai Gorchilov wrote:
> On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov wrote:
>> Just to make sure we are on the same page, here is a list of options I
>> recall being discussed:
>>
>> 1. Using ICP reqnum field as a cache key.
> I don't understand how this option is goin
On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov
wrote:
> On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote:
>> On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote:
>>> Would using ICP reqnum field as a cache key or adding StoreID to
>>> ICP/HTCP requests work for your use cases? I have not fully
On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote:
> On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote:
>> If you want to add an option to use the received ICP reqnum field as a
>> public cache key for lookup, you should be allowed to do that IMO. If
>> you want to add an option to add Store ID to
OK, Amos. Completely agree with your points. I din't want to enter
into such lengthy discussions regarding a small optional feature, that
brings little CPU optimisation. As I said earlier, I don't mind
rewriting same URL twice (once on HTCP, then on HTTP request). Peace!
:-)
Let's discuss working
On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov
wrote:
> On 02/13/2014 06:05 PM, Nikolai Gorchilov wrote:
>> On Thu, Feb 13, 2014 at 10:04 PM, Alex Rousskov wrote:
>>> AFAICT, if Squid always uses URLs for anything
>>> outside internal storage, everything would work correctly and all use
>>> cases
On 02/13/2014 06:05 PM, Nikolai Gorchilov wrote:
> On Thu, Feb 13, 2014 at 10:04 PM, Alex Rousskov wrote:
>> AFAICT, if Squid always uses URLs for anything
>> outside internal storage, everything would work correctly and all use
>> cases will be supported well, without any additional options.
> I
On 14/02/2014 2:20 p.m., Nikolai Gorchilov wrote:
> On Fri, Feb 14, 2014 at 2:04 AM, Amos Jeffries wrote:
>> On 2014-02-14 09:04, Alex Rousskov wrote:
>>>
>>> On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
>>>
I'd suggest first to review all possible StoreID use cases involving
cache p
On Fri, Feb 14, 2014 at 2:04 AM, Amos Jeffries wrote:
> On 2014-02-14 09:04, Alex Rousskov wrote:
>>
>> On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
>>
>>> I'd suggest first to review all possible StoreID use cases involving
>>> cache peers before proceeding further.
>>>
>>> Let's define A as
On Thu, Feb 13, 2014 at 10:04 PM, Alex Rousskov
wrote:
> On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
>
>> I'd suggest first to review all possible StoreID use cases involving
>> cache peers before proceeding further.
>>
>> Let's define A as originating proxy and B - as the next hop proxy in
>
On 2014-02-14 09:04, Alex Rousskov wrote:
On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
I'd suggest first to review all possible StoreID use cases involving
cache peers before proceeding further.
Let's define A as originating proxy and B - as the next hop proxy in
the request forwarding cha
On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
> I'd suggest first to review all possible StoreID use cases involving
> cache peers before proceeding further.
>
> Let's define A as originating proxy and B - as the next hop proxy in
> the request forwarding chain. UDP is alias for both ICP or HT
Amos,
I'd suggest first to review all possible StoreID use cases involving
cache peers before proceeding further.
Let's define A as originating proxy and B - as the next hop proxy in
the request forwarding chain. UDP is alias for both ICP or HTCP query,
while TCP is synonym of the following HTTP
On 2014-02-12 06:51, Niki Gorchilov wrote:
Rising this issue from the dead :-)
On Thu, Jan 16, 2014 at 8:21 AM, Alex Rousskov
wrote:
On 01/15/2014 03:31 PM, Niki Gorchilov wrote:
Actually, it is working. [...] inter cache communication is working
only with
altered URLs but this still does th
Rising this issue from the dead :-)
On Thu, Jan 16, 2014 at 8:21 AM, Alex Rousskov
wrote:
> On 01/15/2014 03:31 PM, Niki Gorchilov wrote:
>> Actually, it is working. [...] inter cache communication is working only with
>> altered URLs but this still does the job:
>> - If UDP is MISS the originati
Hey There,
Just note that the StoreID wiki was written during the design and testing.
I can think about a way to make squid do what you are talking about.
Eliezer
On 16/01/14 00:31, Niki Gorchilov wrote:
Actually, it is working. I found two mistakes in my config - a typo in
cache_peer_access d
On 01/15/2014 03:31 PM, Niki Gorchilov wrote:
> Actually, it is working. [...] inter cache communication is working only with
> altered URLs but this still does the job:
> - If UDP is MISS the originating peer makes a TCP connection to
> destination server and caches the result
> - if UDP is HIT, t
Actually, it is working. I found two mistakes in my config - a typo in
cache_peer_access directive and absence of 'allow-miss' in the
cache_peer definition.
After fixing them, inter cache communication is working only with
altered URLs but this still does the job:
- If UDP is MISS the originating
On Wed, Jan 15, 2014 at 8:35 PM, babajaga wrote:
> Interesting question Did you compare this behaviour to squid2.7 using
> storeurl ?
Nope. I just tried 4.3.2. Same result - both UDP and TCP requests go
with altered URLs.
Interesting question Did you compare this behaviour to squid2.7 using
storeurl ?
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/ICP-and-HTCP-and-StoreID-tp4664307p4664310.html
Sent from the Squid - Users mailing list archive at Nabble.com.
20 matches
Mail list logo
