Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 May 2020 21:59:47 -0700
From:      Benjamin Kaduk <kaduk@mit.edu>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        Benjamin Kaduk <bjkfbsd@gmail.com>, John Baldwin <jhb@freebsd.org>, Rick Macklem <rmacklem@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-projects@freebsd.org" <svn-src-projects@freebsd.org>
Subject:   Re: svn commit: r360859 - projects/nfs-over-tls/sys/rpc
Message-ID:  <20200520045947.GX58497@kduck.mit.edu>
In-Reply-To: <QB1PR01MB3649B6EB237AE6392DF78A2EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
References:  <202005100017.04A0Hd7I058863@repo.freebsd.org> <6739df0b-e621-2ca5-8f92-821822733772@FreeBSD.org> <QB1PR01MB3649E7E08BDFE39C4B8B70A4DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> <QB1PR01MB3649282401A7562B36D3F84EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> <QB1PR01MB36494D1076388A2AD64F5B02DDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> <CAJ5_RoBw-vyPH1EdeKHS=a_kCm3HPoiAkpA%2BrTxhPYcqf3Lz-w@mail.gmail.com> <QB1PR01MB3649B6EB237AE6392DF78A2EDDBE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 12, 2020 at 02:32:29PM +0000, Rick Macklem wrote:
> Benjamin Kaduk wrote:
> [stuff snipped]
> >You can avoid having to play games with putting stuff back on the socket
> >receive buffer by using a custom BIO implementation in userspace that knows
> >how to inject the received message.
> >Rick Macklem wrote:
> >>Actually, what might work for the krpc code is a new MSG_TLSAPPDATA
> >>flag for soreceive_generic(), which says "if the record is not application
> >>data, return an error". (Sort of the opposite of what you said above, but
> >>would perform the same thing.)
> >>This could be used for the krpc soreceive() calls, so that the non-application
> >>data record remains on the socket's receive buffer.
> Well, I'd find it a lot easier to implement MSG_TLSAPPDATA, since I've been
> looking at soreceive_generic() recently.
> I'm guessing that a custom BIO would need to be written and the upstreamed
> to openssl?

It doesn't have to be upstreamed; the idea of the API is that it's modular
and anyone can slot in their own implementation for their particular
communication needs.

-Ben



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200520045947.GX58497>