<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 12, 2016 at 7:55 PM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is it possible to understand, how many data from packet have been sent to OS and try to restore situation on socket and resend the rest of packet again?</blockquote></div><br>Isn't this impossible to know? I assume you are setting the send_timeout option, since according to the documentation, there is no way which a gen_tcp:send/2 can time out.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The problem is that a TCP connection has no way of knowing where your bytes are "hiding" so to speak. The Erlang system might have buffered them and the OS never accepts receiving them. Or the OS has received the bytes, but they are in a TCP window buffer in the kernel somewhere. Or the bytes are in the outgoing TX ring-buffer of your network device. Or traveling through the internet, but getting lost somewhere. Or is sitting somewhere in the receiving hosts buffer queues, but not delivered yet. Or they have been delivered, but you don't know that this is the case.</div><div class="gmail_extra"><br></div><div class="gmail_extra">You need to write your protocol for best effort delivery in general. Otherwise you are in trouble.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">J.</div>
</div></div>