Network api documentation.

[Volker Lendecke]

On Fri, Aug 30, 2013 at 11:16:01AM +0800, Marcelo Araujo wrote:
> 1. Two Interfaces:
> The client try to establish a second connection, however smbd will start a
> second fresh thread that does not share any info about the client SID. I
> tried to change smbd code, but I didn't find a good way to let the new smbd
> thread access the tdb to catch info about the client session, because the
> tdb is locked by the previous smbd thread. (So, I bypass this option now
> and hold it for a while till I solve the second part.)

The tdb should not be locked. What exactly did you try? tdb
files can always be accessed from multiple processes
simultaneously. Individual records can be locked, but that
should never last long.

> 2. RSS:
> I have some 10G Intel interfaces that support RSS, I set the RSS bit and
> set also 2 queues on server side. The client behavior in this case is
> different, the client send a second write command, however the first write
> command was not finished yet and it can be a big problem in currently samba
> architecture. As I saw, I can't write the data from a not continuous offset.

At least for read/write we have async I/O. see "aio read
size" and "aio write size". Setting them to 1 will enable
this feature.

> 
> The steps that I use:
> 1. Enable the SMB2_CAP_MULTI_CHANNEL when respond the negotiation request.
> 2. When the client send FSCTL_QUERY_NETWORK_INTERFACE_INFO(0x001401fc)
> command, I reply the second network interface or the RSS support.
> 3. Copy a file to server, the client(windows 2012) start send write command
> on first interface and try to negotiate with the second interface. (Dual
> NIC case).

That's true multichannel I guess and this is the piece that
requires the architechtural changes I was talking about. We
need to make it work so that the second smbd hands over the
socket to the first smbd. A future version might make it
possible to access the same file handle from different
processes, but that's an even larger change.

> 4. With the RSS, the client send the second write, but I fail to catch it
> on server side, because samba architecture does support only continuous
> offset for the write command in my understanding.

For read and write, that is not necessarily true. See the
aio stuff above. For all other requests, this right now is
still true, although we are bouncing back and forth ideas
how to improve parallelism for other requests too.

> I'm thinking how to deal with this not continuous offset on the write
> command, and I would like to have some suggestions.

Every write command carries its offset. Should just work out
of the box.

> Maybe write a set that will individually take care of the write command,
> that would be outside of smbd, the smbd would pass the write offset to this
> new thread or process, this new thread/process will have such like a queue
> where it will organize the write in a continuous offset. This new
> thread/process would handle all write commands from any smbd thread that
> has smb3 multichannel negotiated.

See source3/modules/vfs_default.c, function
vfswrap_pread_send. That is *exactly* what is happening
right now. By the way, are we talking about Samba master?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de

*****************************************************************
visit us on it-sa:IT security exhibitions in Nürnberg, Germany
October 8th - 10th 2013, hall 12, booth 333
free tickets available via code 270691 on: www.it-sa.de/gutschein
******************************************************************