<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 8:15 AM, Vinoth Kumar <span dir="ltr"><<a href="mailto:vinothsparrow@live.com" target="_blank">vinothsparrow@live.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p style="margin-bottom:1em;border:0px;font-size:14px;vertical-align:baseline;clear:both;font-family:Arial,'Liberation Sans','DejaVu Sans',sans-serif;line-height:17.804800033569336px">

Does gen_tcp supports non-blocking send ?</p><p style="margin-bottom:1em;border:0px;font-size:14px;vertical-align:baseline;clear:both;font-family:Arial,'Liberation Sans','DejaVu Sans',sans-serif;line-height:17.804800033569336px">

I have tried gen_tcp:send which returns the ok while the packets has not been sent to the receiver. Whether any mechanism in erlang to check the sent message delivary?</p></blockquote></div><br>I think you must consider you may be going in a direction which TCP does not support, in general. The danger is you end up in a situation where you are bending the rules of TCP to a point where the guarantee you expect is not even there. Only turmoil is on this path.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">The problem is Erlang can only see so far. Once it delivers data to the kernel, the kernel is in control of what happens and you have relatively few ways to ask the kernel what it is doing. Worse, even if the kernel manages to send data, the NIC might queue you. Modern NICs have buffers in the excess of 4096 packets. And you have even fewer ways to ask those about their state. And if the NIC manages to send data, the hops in route might queue you.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><div><br></div>-- <br>J.
</div></div>