collapsed_forwarding and ICP
If I have a peer and it has collapsed_forwarding on, at what point will it return an ICP_HIT to me? E.g., 1) As soon as there's an outstanding (therefore collapsed) request for it? 2) As soon as there's a cacheable response in-flight for it? 3) Only when the entire response is in-cache? My reading of the code is that it's #1. Do I have this right? If that's the case: - On the plus side, this helps collapse requests across peers. - On the down side, it seems like there's the potential for requests to go to peers, only to find that the response is uncacheable. Thanks, -- Mark Nottingham m...@yahoo-inc.com
Re: collapsed_forwarding and ICP
fre 2009-02-06 klockan 10:07 +1100 skrev Mark Nottingham: If I have a peer and it has collapsed_forwarding on, at what point will it return an ICP_HIT to me? E.g., 1) As soon as there's an outstanding (therefore collapsed) request for it? 2) As soon as there's a cacheable response in-flight for it? 3) Only when the entire response is in-cache? My reading of the code is that it's #1. Do I have this right? Probably. If that's the case: - On the plus side, this helps collapse requests across peers. Yes. - On the down side, it seems like there's the potential for requests to go to peers, only to find that the response is uncacheable. Yes, and the slower the origin is to respond the more you'll see of this. Should be trivial to add a tuning knob to ICP for this. The not yet known if they may be cached objects have a special KEY_EARLY_PUBLIC flag set. See icpCheckUdpHit() for a suitable spot. htcpCheckHit would also need the same. Regards Henrik
Re: collapsed_forwarding and ICP
Thanks. I may have a look into putting those knobs in... On 06/02/2009, at 11:18 AM, Henrik Nordstrom wrote: fre 2009-02-06 klockan 10:07 +1100 skrev Mark Nottingham: If I have a peer and it has collapsed_forwarding on, at what point will it return an ICP_HIT to me? E.g., 1) As soon as there's an outstanding (therefore collapsed) request for it? 2) As soon as there's a cacheable response in-flight for it? 3) Only when the entire response is in-cache? My reading of the code is that it's #1. Do I have this right? Probably. If that's the case: - On the plus side, this helps collapse requests across peers. Yes. - On the down side, it seems like there's the potential for requests to go to peers, only to find that the response is uncacheable. Yes, and the slower the origin is to respond the more you'll see of this. Should be trivial to add a tuning knob to ICP for this. The not yet known if they may be cached objects have a special KEY_EARLY_PUBLIC flag set. See icpCheckUdpHit() for a suitable spot. htcpCheckHit would also need the same. Regards Henrik -- Mark Nottingham m...@yahoo-inc.com
