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

Volker Lendecke Volker.Lendecke at SerNet.DE
Fri Jul 25 02:26:03 MDT 2014


On Thu, Jul 24, 2014 at 06:51:51PM +0200, Stefan (metze) Metzmacher wrote:
> 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.

Those 112 bytes are certainly no problem, sure. I just
stumbled over the fact that we have a structure that can
exist multple times per client machine but that carries
stuff that definitely only makes sense to exist once per
client machine. The message context (a pure SMB1 concept) is
one of those fields that just don't make sense in a SMB2
environment. Having that in a structure that will in the
future exist multiple times per client machine is confusing
to me. So I thought that to make the code more
understandable, we need a structure that can exist just once
per client machine.


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, mailto:kontakt at

More information about the samba-technical mailing list