[gdal-dev] GDAL RPC protocol to make GDAL (more) failsafe

[David Shean]

Even,
This sounds great.  I'm guessing RPC in this context stands for "Remote Procedure Call."  It seems like this could potentially lead to some confusion with existing GDAL functionality (e.g., gdal_rpc.cpp) and options (e.g. RPC_DEM) where RPC stands for "Rational Polynomial Coefficients" used during warping/orthorectification.  I suppose that as long as the documentation is clear, this won't be a major issue.  Just thought I'd mention it.
-David

On Feb 5, 2013, at 3:55 PM, Even Rouault wrote:

> Hi,
> 
> Just to inform you that I've just commited in trunk a new feature.
> 
> See http://trac.osgeo.org/gdal/ticket/4979 :
> 
> """
> When dealing with some file formats, particularly the drivers relying on third-
> party (potentially closed-source) libraries, it is difficult to ensure that 
> those third-party libraries will be robust to hostile/corrupted datasource. 
> The implemented solution is to have a fake driver that will expose a 
> GDALClientDataset object that will forward all the API calls to another 
> process ("server") where the real driver will be run. This way, if the server 
> segfaults, the calling process will be unaffected and will report a clean error 
> instead of segfaulting itself. 
> This is controlled by setting the GDAL_RPC config option to YES. The option can 
> also be set to a list of file extensions that must be the only ones to trigger 
> this mechanism (e.g. GDAL_RPC=ecw,sid) 
> For now, the server launched is the gdalserver executable on Windows. On Unix, 
> the default behaviour is to just fork() the current process (the gdalserver 
> executable can also be execvp()'ed by forcing GDAL_RPC_SERVER=YES). 
> To avoid the cost of forking()/CreateProcess(), a pool of connections is used. 
> This is controlled with the GDAL_RPC_RECYCLE config option that is set to YES 
> by default. 
> Note: the client/server approach can also be used for thread unsafe drivers 
> (not actually tested). 
> """
> Demo with a corrupted ECW file :
> Normal GDAL run :
> $ gdalinfo corrupted.ecw -checksum
> Driver: ECW/ERDAS Compressed Wavelets (SDK 3.x)
> Files: corrupted.ecw
> Size is 128, 128
> Coordinate System is:
> [ ... snip ... ]
> Band 1 Block=256x256 Type=Byte, ColorInterp=Gray
> Segmentation fault
> 
> Under the RPC mechanism :
> 
> $ gdalinfo corrupted.ecw -checksum --config GDAL_RPC YES
> 
> Driver: ECW/ERDAS Compressed Wavelets (SDK 3.x)
> Files: corrupted.ecw
> Size is 128, 128
> Coordinate System is:
> [ ... snip ... ]
> Band 1 Block=256x256 Type=Byte, ColorInterp=Gray
> ERROR 1: Read from pipe failed
> ERROR 3: Checksum value couldn't be computed due to I/O read error.
> 
>  Checksum=0
>  Mask Flags: 
>  Offset: 0,   Scale:0
> 
> Of course, there's a small performance cost associated to the RPC round-trips.
> 
> 
> Best regards,
> 
> Even
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev