dCap 2.47.6
========================================================================

dCap switched from /opt to /usr following the FHS standard. Please be aware
when updating. dccp also has a man page now.
------------------------------------------------------------------------
r15647 | tigran | 2011-05-25 10:08:19 +0200 (Wed, 25 May 2011) | 8 lines

Changed paths:
   M /trunk/modules/dcap/src/dcap.c

libdcap: do not fallback to plain IO on tunnel error.

current behavior is to fall back to plain when trying to talk to
tunneled door.

Acked-By: Dmitry Litvintsev
Patch: http://rb.dcache.org/r/3379/


------------------------------------------------------------------------
r15771 | pmillar | 2011-06-15 10:26:26 +0200 (Wed, 15 Jun 2011) | 16 lines

Changed paths:
   M /trunk/modules/dcap/src/dcap.h.in
   M /trunk/modules/dcap/src/dcap_lcb.c

dcap: add support for flushing the LCB cache

The dcap library includes a local cache buffer, which stores the 
results of recent reads allowing reads near the same area to be 
resolved by the cached entry rather than by asking the server for the 
data.

This stateful nature of the client makes some testing harder; 
therefore this patch adds support for the dc_lcb_flush function.  
This flushes the local cache buffer, allowing easier testing.

Patch: http://rb.dcache.org/r/3471
Acked-by: Tigran Mkrtchyan


------------------------------------------------------------------------
r15772 | pmillar | 2011-06-15 13:47:32 +0200 (Wed, 15 Jun 2011) | 25 lines

Changed paths:
   M /trunk/modules/dcap/src/dcap_lcb.c

dcap: fix overread when LCB is enabled

The LCB caching breaks a read into block-size chunks that it reads to 
satisfy some particular read request.  Once the byte-range of the 
request is satisfied, the read call returns.  Some client client 
(dccp, for example) don't bother to figure out how big is the 
requested file but simply keep reading a fixed sized block and 
terminate when a read returns zero.  This means that a read operation 
may request more data than is present in a file.

The current code-base doesn't cope with this possibility.  It notices 
that the final cache block has a short read, which it takes as some 
kind of problem.  As a fall-back mechanism, the code then disables LCB 
and satisfies the read request (and any subsequent ones) without 
caching.

The new code will attempt to read a second time after a short-read.  
If the second read is zero-length then EOF is assumed and the request 
is returned with all the data collected so-far.

Patch: http://rb.dcache.org/r/3474/

------------------------------------------------------------------------
r15774 | pmillar | 2011-06-16 11:56:57 +0200 (Thu, 16 Jun 2011) | 24 lines

Changed paths:
   M /trunk/modules/dcap/src/dccp.c

dcap: work-around LCB poor performance in dccp

We've had reports of dccp taking a very long time to download files 
when the LCB is enabled.  This is because the LCB will split a large 
request block into multiple cache blocks and fetch each cache block 
independently.  These independent requests introduce additional 
round-trips and force the TCP "pipe" to be flushed, so crippling the 
transfer performance.

Rather than fix the underlying problem in LCB, which will require 
substantial restructuring of the LCB code, we work around the issue 
by forcefully switching off LCB in dccp.  This is legitimate as, in 
dccp, we know that any caching will never be used.

NB this is an ugly, temporary work-around.  Other clients that make 
large file requests may no forcefully disable LCB, so this patch only 
addresses the issue with dccp.

Ticket: http://rt.dcache.org/Ticket/Display.html?id=6305
Patch: http://rb.dcache.org/r/3473/

------------------------------------------------------------------------
r16760 | tigran | 2011-12-12 10:28:43 +0100 (Mon, 12 Dec 2011) | 5 lines

Changed paths:
   M /trunk/modules/dcap/src/dcap_lseek.c

libdcap: fix lseek on SEEK_END

Signed-off-by: Guenter Duckeck <Guenter.Duckeck@physik.uni-muenchen.de>
Ticket: #6803

------------------------------------------------------------------------
r16803 | bernardt | 2011-12-19 16:29:21 +0100 (Mon, 19 Dec 2011) | 4 lines

Add man page for dccp