<div dir="ltr"><div><div><div><div><div><div>Let's see here:<br><br>> - to detect if a client is connected from what ports;<br></div>Well yes. UDP doesn't have connections, as Sean noted. So how would you even define this, nevermind detect it?<br><br>> gen_udp:send/4 always returns ok no matter what if port and/or ip is wrong<br></div>What do you mean "wrong"? Do you mean "not the place I wanted to send it"? Remember, there's no "connection", so there's no particular place packets "have" to go to be "correct" (at least not in any sense gen_udp could be expected to determine).<br><br>> gen_udp:recv is blocking (and with Timeout parameter even worse) and
thus a design based on passive sockets leads to serialized
processing of client requests;<br></div>gen_udp provides an "active" mode which means you don't have to call recv, but rather receive each packet as a message to your process. That should do waht you want. But it looks like you know that:<br><br>> if controlling process is used to handle other messages (from child procs) other then {udp, ...} message it would be <br> unpractical from parallelization point of view of client request processing<br></div>Why? Processes are quite capable of handling messages from multiple sources. If sheer volume of messages is your concern, I'd suggest benchmarking your system before getting too hung up on receiving all the messages in one process. If your other messages result in slow or blocking behaviour then you need to reconsider your design.<br><br></div>Cheers,<br><br></div>B<br><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 7:16 PM, Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>this is easy on client side but on the server side there must be an interaction<br></div>with spawned processes that actually use that socket to send data.<br><br></div>other thing I found hard to achieve in UDP is:<br> - to detect if a client is connected from what ports;<br></div> - sending detection errors from server to client :<br> gen_udp:send/4 always returns ok no matter what if port and/or ip is wrong.<br></div> otherwise it would have been easy to implement something pinging the client with an empty udp packet<br></div> and (possibly, again) to receive response;<br></div>- gen_udp:recv is blocking (and with Timeout parameter even worse) and thus a design based on passive sockets leads to serialized processing of client requests;<br></div></div>- if controlling process is used to handle other messages (from child procs) other then {udp, ...} message it would be <br></div> unpractical from parallelization point of view of client request processing<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 4, 2016 at 4:43 PM, Sean Cribbs <span dir="ltr"><<a href="mailto:seancribbs@gmail.com" target="_blank">seancribbs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">UDP is a connection-less datagram protocol, so there's no timeout inherent in the protocol. However, you may have timeouts on:<div><br></div><div>1) receiving a datagram (nothing arrived)</div><div>2) sending a datagram (things went very badly)</div><div><br></div><div>However, those are timeouts internal to Erlang, from your process to the socket driver. If you are using the {active, true} option (which it sounds like you are), you should use an 'after' clause in your 'receive' to implement timeouts, or use the trailing timeout in the return tuple of a gen_server/gen_fsm callback.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Feb 4, 2016 at 6:29 AM, Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>How can be detected a timeout on an active UDP socket?<br><br></div>controlling process receives the message:<br>{udp, Socket, Host, Port, Bin}<br><br></div>and after a process is spawned to handle that data:<br>spawn(fun() -> handle_pckt(Socket, Host, Port, Bin) end),<br><br></div>Q: how the spawned or controlling process is able to detect <br>that a timeout on this UDP socket occurred ?<br><br></div>documentations does not mention anything about timeout on active sockets<br><br></div>Thanks,<br><br></div>/Bogdan<br><br><br><div><div><br></div></div></div>
<br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div>