I don't mind upwinding it. These different reactions and input only help me
design my things better. Very pleased with the discussion so far.
Den mån 13 aug. 2018 20:26Viktor Dukhovni
skrev:
>
>
> > On Aug 13, 2018, at 2:13 PM, Jordan Brown
> wrote:
> >
> > I'm curious: how did this ever work
Oh wow! That's perfect!
Now the docs are very clear on this and essentially SSL _does_ support
half-closed sockets.
Thanks for clarifying this, TLS 1.3 seems like a big step forward.
Den sön 12 aug. 2018 kl 21:05 skrev Kurt Roeckx :
> On Sun, Aug 12, 2018 at 08:49:35PM +0200, Kurt Roeckx wrote:
that I’m also interested, as a contributor to Libevent,
> which provides SSL-socket support.
>
> I’ve opened an OpenSSL issue:
>
> https://github.com/openssl/openssl/issues/6911
>
> to collect the details on how a graceful shutdown can be implemented in
> Libevent.
>
> Thanks,
down does not return with any data.
Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug?
Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni <
openssl-us...@dukhovni.org>:
>
>
> > On Aug 1, 2018, at 2:27 AM, Alex H wrote:
> >
> > Is it possible
I would appreciate an answer to this question, it's holding me back and
should be a simple yes/no.
And yes, "client_notify" is a typo and should be "close_notify".
Thanks
Den ons 1 aug. 2018 kl 08:27 skrev Alex H :
> Hi,
>
> I have trouble understanding the
Hi,
I have trouble understanding the details of TLS shutdown. I get the basics
but,
Is it possible to receive data after calling SSL_shutdown? Reading the
specs and docs leaves this rather blurry.
That is, after sending a close_notify, can I receive data before getting my
client_notify response?
Hi,
I have a custom BIO_TYPE_MEM BIO with write and read callbacks that map to
a networking socket. I'm getting a lot better performance by using the
MSG_MORE flag of the Linux send syscall to "cork" segments of a stream
together.
So far I have guessed whether to pass MSG_MORE or not based of the
@openssl.org; Michael Wojcik; Alex H
> > Subject: Re: [openssl-users] Receive throttling on SSL sockets
>
> > TLS could (but as far as I can tell does not) have such a mechanism. It
> could have a window, like TCP, where the receiver
> > would say "you can send me 64K
Yeah TCP is really the same as TLS in terms of being "bidirectional". Even
if you stop polling for readable and never call recv, you will still
receive ACKS for whatever you write.
A receive window for TLS implemented completely ontop of TCP would solve
this issue and allow applications to truly t
using
some kind of internal backup queue for cases like these, right?
2018-05-19 11:02 GMT+02:00 Alex H :
> Okay that's a good theoretical answer but practically not very useful.
>
> I know for instance Node.js to implement their Streams interface with both
> TCP and SSL sockets. Th
ottle only one side.
>
>
>
> *From: *Alex H
> *Reply-To: *openssl-users
> *Date: *Friday, May 18, 2018 at 7:21 PM
> *To: *openssl-users
> *Subject: *[openssl-users] Receive throttling on SSL sockets
>
>
>
> How do you properly implement receive throttling on SSL soc
How do you properly implement receive throttling on SSL sockets without
hindering writing?
As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled
simply by stop polling for readable events on the underlying raw TCP
socket. SSL_write still could require reading of data so simply s
12 matches
Mail list logo
