"New" SSL - a problem (which could be mine) and a suggestion

[Steve Davis]

I'm adding SSL to an http server, I'm only supporting the new_ssl
implementation, and thus it's alpha quality for at least as long as
the new_ssl implementation remains that way ;). However, be aware that
the following comments apply to *new_ssl* and not "old ssl".

1) A problem: I'm finding that the ssl_accept hands over client
sockets that appear to close out immediately, frequently and
unexpectedly. The real problem is that this issue is intermittent. In
about 50% of cases of a connection I'm getting:

=INFO REPORT==== 18-Aug-2009::03:15:24 ===
SSL: Peer did not send close notify alert.

...but no other error(s) at all (This info report is generated from
the  ssl_connection module in the ssl app).

In about 20% of these unexpected close cases, the socket also errors
out with
[[{initial_call,{ewok_tcp_srv,accept,['Argument__1']}},
  {pid,<0.3865.0>},
  {registered_name,[]},
  {error_info,{error,{badmatch,{error,closed}},
                     [{ewok_tcp_srv,accept,1},
{proc_lib,init_p_do_apply,3}]}},
  {ancestors,[ewok_http_srv,ewok_sup,<0.3830.0>]},
  {messages,[]},
  {links,[<0.3841.0>]},
  {dictionary,[]},
  {trap_exit,false},
  {status,running},
  {heap_size,610},
  {stack_size,24},
  {reductions,584}],
 []]

Occasionally, ssl:send *silently* but entirely fails.

Since the exact same socket handling code flow is used for the plain
gen_tcp, which doesn't suffer from these issues, I'm suspecting that
it isn't my code here. I'm making appropriate checks later in the
handler to check for closed-out/timed out sockets but these checks are
never reached/triggered.

My question is whether this a known issue? i.e. if not, then I'll have
to find time to pull out a vanilla repro from the server codebase to
effectively bug-report -- that kind of time I am sadly sorely short
of.


2) A suggestion: new_ssl is generally easier to use, however it
suffers from one important API usage issue as old ssl...
In order to use setopts/send/recv/close you need to know the transport
(gen_tcp or ssl) throughout the socket lifetime. This means that
throughout the later handling of the client socket, when you really do
not (and should not have to) care what transport is being used, you
are forced to case check at every turn whether the socket is ssl or
inet.

My suggestion is design-level and is that either inet/gen_tcp should
be made aware of the differing transports or that some platform level
abstracted interface to the socket implementation be provided so you
can call socket:set_opts, socket:send, socket:recv, socket:close
without checking which module to invoke. This would improve usability
considerably.



BR,
/sd