Wed Jun 30 23:44:30 CEST 2004
On Wed, Jun 30, 2004 at 09:16:55PM +0200, Peter H|gfeldt wrote:
> On Wed, 30 Jun 2004, Carsten Schultz wrote:
> > I just noticed that a problem I thought had gone away is still there.
> > In November 2003, Alexey Shchepin reported
> > (http://www.erlang.org/ml-archive/erlang-questions/200311/msg00173.html)
> > | * ssl:accept locks when when one TCP connection is established, but
> > | SSL handshake is not finished. E.g. if Yaws is listen for SSL
> > | connections on port 443 and someone runs "telnet this.server 443"
> > | (note that this is not SSL-enabled telnet), then noone will be
> > | able to retreive web pages via this port until this connection
> > | will be closed.
> > Has anything happened in this regard?
> In Nov 3, 2003 in response to Alexey's question I wrote:
> In Erlang/OTP SSL you can have several processes, each waiting for
> an ssl:accept/N on one and the the same port. That is needed to
> obtain acceptable (no pun intended) parallellism.
> That it not practically possible with gen_tcp:accept/N (if you try
> it you will get an error return). I think gen_tcp should accept
> multiple accepts as well.
> That is, if you have the very simple approach with only one process
> calling ssl:accept/1 in series, you will get the behaviour described.
> What you should do is to have several processes in parallel waiting for
> the result of calling ssl:accept/1 (and spawning a new process when a
> return is obtained).
> Also, to avoid an indefinite wait for an accept call, and thus avoid
> that a file descriptor will never be returned, you should use
> ssl:accept/2 with timeout.
Back then you also wrote :-)
| I also agree that there should be some kind of "pre_accept" that
| returns a "raw" non-SSL socket, to be closed on reasons you have
I really do think that this is the way to go. Your solution above
does not convince me. How many accepts should I run in parallel?
What should the timeout be?
Why this is a problem even without malicious client processes is that
it is not unusual to have *user* *interaction* on the client side in
the course of the SSL connect. To avoid not being able to accept new
connections I would need to have as many parallel accepts as users
simultaneously looking at certificates and pondering whether to trust
them. I would not know how to obtain a reasonable upper bound on
Nevertheless, your answer pointed me in a direction to partly fix the
Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin
PGP/GPG key on the pgp.net key servers,
fingerprint on my home page.
More information about the erlang-questions