[linux-cifs-client] Add support infrastructure for Named Pipe

[Steve French]

On Mon, Oct 19, 2009 at 1:54 PM, Gerald Carter <jerry at plainjoe.org> wrote:
> Steve,
>
> Just a few points.  Feel free to ignore or respond.  The only
> point I'm making here is that other solutions do exist already.
> I'm not advocating our code as a solution for this debate.
> Just pointing out that this is a well traveled problem (as you
> know).

I agree that Likewise librpc would address some of this,
but haven't seen any progress in getting likewise into other distros
directly (or indirectly by moving it's librpc into samba).  Any progress
on getting this into more major distros?

I would much prefer to map an existing lgpl or bsd "librpc" (preferably to
existing cifs code when rpc is not going over tcp), but for the purposes
of a "system library" for common tasks, we need something in all of
the distros.

> Steve French wrote:
>
>> a few quick points:
>> 1) Easier: Even without extending cifs.ko with anny new ioctls, we
>> already can do simple RPC operations over existing cifs.ko today (with
>> prototype user space code that does the DCE part bind etc.).
>> Currently there is no user space SMB client library that could be used
>> broadly by Linux applications and tools, although libsmbclient can be
>> used by those which are gpl.
>
> The Likewise rdr driver inside lwiod already does all this. [1]
> The client library is LGPLv2.1+.  However, it does require IPC
> to a locally running daemon so it does handle the credential/connection
> caching.

IPC to Winbind or to Likewise daemon for credentials (once) is fine,
although it would be better IMO to cache credentials using Dave
Howell's existing kernel mechanism for caching keys.


>> 2) Affinity with other file objects: Although not available
>> in Linux -
> ...
>> 3) Usability: Since the file system client does not use
>> the server's (or smbclient's) smb.conf file for configuration
>> settings (security levels, signing etc.), it can be confusing
>> e.g. to list shares with smbclient (with looser security
>> settings) and not be able to connect to the share (with cifs.ko
>> using stricter security settings).
>
> Ditto.
>
>> 4) Performance: The cifs kernel client can connect to a server and
>> keep a session - but with smbclient and the libsmbclient model in
>> general you can end up reconnecting dozens of times to the server from
>> the same client (even though a session to the server already exists in
>> kernel).  In addition connecting via to the same server from via
>> smbclient from (when you already e.g. have a kernel mount to it) can
>> cause the "SMB NAT problem" in some versions of Windows.
>
> Connection caching I will agree on which I mentioned in point #1.
> Although I don't believe throughput is really an issue on named
> pipes so that part of performance is not valid IMO.

I have seen examples where the redundant session setups etc. does make
a difference (server to server migration moves a lot of rpc traffic,
and using an existing session can cut the traffic by more than 1/2).
Certainly the load on Samba server (in particular) by running
extra processes per client can be significant when multiplied
across many clients to same server.

-- 
Thanks,

Steve