> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Alex H
> Sent: Saturday, May 19, 2018 15:53
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Receive throttling on SSL sockets
> > Flow control really, really, *really* seems like
I should make it clear that I don't have a stake here. Lack of flow
control hasn't caused me problems personally, and I'm not responsible
for implementing and maintaining a TLS infrastructure. This is purely
an intellectual exercise for me.
There were comments suggesting that, because TLS is an
@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
> From: Jordan Brown [mailto:open...@jordan.maileater.net]
> Sent: Saturday, May 19, 2018 14:08
> To: openssl-users@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
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
On 5/19/2018 6:51 AM, Michael Wojcik wrote:
> Right. And TCP is an ordered byte-stream protocol. That means to
> receive a control message from the peer, the local stack *must* have
> received everything transmitted prior to it. (Modulo SACK, but SACK'd
> data preceeded by a gap is invisible to the
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Salz, Rich via openssl-users
> Sent: Saturday, May 19, 2018 08:48
> To: Alex H; openssl-users@openssl.org
> Subject: Re: [openssl-users] Receive throttling on SSL sockets
> There are TLS control me
Subject: Re: [openssl-users] Receive throttling on SSL sockets
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. They both have pause / resume functions for receive-throttling
I think the best solution would be to simply state in the documentation of
my implementation that "throttling receives on SSL sockets will
significantly reduce data receive but will not guarantee a total halt".
Agree?
What do you think of the way Node.js handles this? They _must_ be
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. They both have pause / resume functions for
receive-throttling and I've tested it with SSL and it seems to work som
TLS is a bidirectional protocol. You can’t throttle 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 sockets without
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
Laura Arhire wrote:
> if (pthread_create (&thr, NULL, print_message_function, (void *)
> &data) != 0)
> printf("Warning, create did not work for thread #%d\n",
> i);fflush(stdout);
> else
> {
> Sleep(1000);
> ClientSocket *client = Socke
create new threads - so I was wondering if I might have missed
something clearing up resources (the pthread_create method returns with
EAGAIN, which means insufficient resources). This only happens with ssl
sockets when I connect a client, if I use normal sockets everything
works well.
hello
the SSL Layer sits between the application (say HTTP) and the
transport (TCP)
so it should hide all transport calls like socket()
connect() accept()
it does this and if i am writing an SSL application
i don't need to know SSL handshake details
is this right ?
-SIGTERM
15 matches
Mail list logo
