[erlang-questions] ssl:shutdown(Socket, write) unexpected behavior?

[Jay Doane]

Craig,

Thank you for the detailed reply! I appreciate the advantages of using some
kind of header to send metadata (destination path immediately comes to mind
as also possibly useful). The main use case I had considered for using
ssl:shutdown(S, write) was to enable interaction from simple command line
tools like netcat.

But putting aside for the moment whether or not that's a good idea, I'm
still curious about OTP's ssl documentation, which seems to indicate that
it should be possible to do:
http://erlang.org/doc/man/ssl.html#shutdown-2

Am I misinterpreting the documentation, or is this a bug?

Thanks,
Jay

On Wed, Jun 8, 2016 at 5:32 PM, zxq9 <zxq9@REDACTED> wrote:

> On Wednesday 08 June 2016 16:25:19 Jay Doane wrote:
> > I'm working on an erlang network file copier that should be able to
> > use either tcp or ssl, depending on its configuration.
> >
> > The basic idea is that it listens on a specified port, and writes
> > anything it receives to a file, then with the *same* connection,
> > responds to the sender with some statistics, and finally closes the
> > connection.  A demonstration version can be found here:
> > https://gist.github.com/jaydoane/65dc6b005788af3c49e2866ea7d03f09
> >
> > For basic tcp, this can be achieved by the sender doing a
> > gen_tcp:shutdown(Socket, write) after sending the payload, which -- if
> > the receiving socket is configured with {exit_on_close, false} --
> > closes the connection in the sending direction, but leaves it open to
> > receive the response. For example, this test works:
>
> In general it is not the easiest thing to manage several layers of the
> communication stack as part of a single protocol. What I mean is, there
> are several levels here, and the transport layer (TCP/UDP/SCTP -- which
> is what TLS is supposed to be wrapping) is below the application layer
> you are trying to build on top. So whether or not you *can* get the
> effect you want by closing one direction on the connection from one side
> and detecting that change on the other as an application-level signal
> isn't really the point -- its probably not a good idea to use this as a
> hidden protocol "verb".
>
> For this kind of thing I usually add a 32-bit header that is the total
> length to be sent in bytes, and have the receiver add up how much it is
> receiving, and stop once it receives that much or times out in the middle.
> At the moment your file transfer system has no indication which condition
> is occurring:
>
> * Did the other end finish sending, but improperly close its 'write'
>   direction of the transport layer.
> * Did your side improperly interpret the other side closing its 'write'
>   direction. If so is this a driver issue over which you have no control?
> * Did the other side drop off the network?
> * Did the other side stall?
> * Is that all there is to receive? (A few unknowns rolled into one...)
>
> Having a known size is much more reliable and also allows you to be more
> flexible with how you buffer the received data.
>
> Now how to react?
>
> Once Size == Received, then you initiate the stats response, and have the
> receiver close the connection. Or you respond with the stats, receive an
> ack from the sender, and then close the connection. Or whatever. My point
> being that the application-level signal should not be the transport-layer
> event.
>
> You're getting close to a nice little utility there. :-) Keep at it!
> Socket programming in Erlang can be a wonderful thing.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160609/01498c1d/attachment.htm>