SMB3 Multi-Channel (Re: What I'm working on)

[Stefan (metze) Metzmacher]

Hi Volker,

>> The commits with TODO/REVIEW are the chance which where added or modified.
> 
> One broader question: You move a lot of stuff from
> smbd_server_connection to smbXsrv_connection, and I have
> reviewed most of that already. If I understand it correctly,
> smbXsrv_connection is going to be per TCP connection. Under
> this assumption I ask myself whether it really makes sense
> to migrate everything for SMB1 there that will definitely
> only exist once per client machine, there won't be any multi
> channel over SMB1. Also, it adds burden to every incoming
> SMB2 TCP connection. First, there is negligible memory
> overhead, but also from a clarity point of view I would like
> to raise the question whether we need something that won't
> ever have more than one instance per client machine. With
> the smbXsrv_connection this is a bit blurred to me as a
> casual reader of this.

There're two things:

1) I'd like to remove as much as possible from smbd_server_connection.
It is more or less a legacy structure to keep vfs modules happy.
smbd_server_connection is also used in situations where we don't really
have a SMB connection. In future the name will be a bit miss leading
as it doesn't represent exactly one transport connection, but it makes it
easier to our substution and similar code, as %I will always expand to
the smbd_server_connection->remote_address, which is the address
of the first connection with a given client guid.

2) smbXsrv_connection is the structure that also currently represents
a TCP connection for smb1 and smb2, so that is the place to put things
we don't require to in smbd_server_connection.
I don't think the 112 (if I counted correctly) extra bytes for .smb1,
should not matter much, a talloc_chunk header consumes 96 bytes.
If it becomes a problem in future we can move .smb1 and .smb2
into a union.

I hope this explains the aims a bit more.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140724/fa16b59e/attachment.pgp>