On Mon, Nov 04, 2024 at 05:59:55PM +0100, Jan Klemkow wrote:
> On Fri, Aug 02, 2024 at 11:04:19PM GMT, Jan Klemkow wrote:
> > On Fri, Aug 02, 2024 at 10:55:09PM +0200, Jan Klemkow wrote:
> > > On Wed, Jul 24, 2024 at 10:34:19AM +0200, Theo Buehler wrote:
> > > > On Wed, Jul 24, 2024 at 09:19:47AM +0200, Jan Klemkow wrote:
> > > > > On Wed, Jul 24, 2024 at 06:47:27AM +0100, Jason McIntyre wrote:
> > > > > > On Tue, Jul 23, 2024 at 07:16:09PM +0200, Jan Klemkow wrote:
> > > > > > > This diff adds TLS support via libtls to tcpbench.  So, we are able to
> > > > > > > measure TLS throughput performance.
> > > > > > > 
> > > > > > > Its based on the tls code of nc(1).  But, I just took the essentials
> > > > > > > which is needed in the context of tcpbench.  We just transfer test data
> > > > > > > and have no need for authentication nor key handling.  In client mode,
> > > > > > > it just accepts every certificate.  In server mode, it creates a self
> > > > > > > signed certificate on the fly.  Thus, its easy to use.
> > > > 
> > > > While I understand the desire of benchmarking TLS and making this as
> > > > easy as possible for the benchmarker, I'm not a fan of generating an
> > > > (invalid per RFC 5280) certificate on the fly.
> > > 
> > > I would prefer to generate a certificate by default for ease of use.
> > > But, I applied all your improvements.
> 
> Here is a version of this diff without on the fly generation of
> certificate and key.  So, this diff is much smaller and we can do this
> afterward.

ok