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