[erlang-questions] UDP active socket timeout

[Bernard Duggan]

Let's see here:

>  - to detect if a client is connected from what ports;
Well yes. UDP doesn't have connections, as Sean noted. So how would you
even define this, nevermind detect it?

> gen_udp:send/4 always returns ok no matter what if port and/or ip is wrong
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).

> 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;
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:

> if controlling process is used to handle other messages (from child
procs) other then {udp, ...} message it would be
  unpractical from parallelization point of view of client request
processing
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.

Cheers,

B


On Fri, Feb 5, 2016 at 7:16 PM, Bogdan Andu <bog495@REDACTED> wrote:

> this is easy on client side but on the server side there must be an
> interaction
> with spawned processes that actually use that socket to send data.
>
> other thing I found hard to achieve in UDP is:
>  - to detect if a client is connected from what ports;
>  - sending detection errors from server to client :
>    gen_udp:send/4 always returns ok no matter what if port and/or ip is
> wrong.
>    otherwise it would have been easy to implement something pinging the
> client with an empty udp packet
>    and (possibly, again) to receive response;
> - 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;
> - if controlling process is used to handle other messages (from child
> procs) other then {udp, ...} message it would be
>   unpractical from parallelization point of view of client request
> processing
>
> On Thu, Feb 4, 2016 at 4:43 PM, Sean Cribbs <seancribbs@REDACTED> wrote:
>
>> UDP is a connection-less datagram protocol, so there's no timeout
>> inherent in the protocol.  However, you may have timeouts on:
>>
>> 1) receiving a datagram (nothing arrived)
>> 2) sending a datagram (things went very badly)
>>
>> 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.
>>
>> On Thu, Feb 4, 2016 at 6:29 AM, Bogdan Andu <bog495@REDACTED> wrote:
>>
>>> Hi,
>>>
>>> How can be detected a timeout on an active UDP socket?
>>>
>>> controlling process receives the message:
>>> {udp, Socket, Host, Port, Bin}
>>>
>>> and after a process is spawned to handle that data:
>>> spawn(fun() -> handle_pckt(Socket, Host, Port, Bin) end),
>>>
>>> Q: how the spawned or controlling  process is able to detect
>>> that a timeout on this UDP socket occurred ?
>>>
>>> documentations does not mention anything about timeout on active sockets
>>>
>>> Thanks,
>>>
>>> /Bogdan
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>
> _______________________________________________
> 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/20160208/58d10d9f/attachment.htm>