Some questions about the behaviour of active gen_udp socket

I am in the process of implementing a driver for controlling a radio tranceiver. For the API, I am using a number of functions that are very similar to the API of gen_udp. Now the following issues are not clear to me:

  • In the case where a socket is opened in active mode, i.e. {active, true} or something similar, then what is the effect of calling the function gen_udp:recv/2,3? According to the documentation,

    Receives a packet from a socket in passive mode

    but the result for active mode is undocumented. Does this return an error or is some value returned?

  • What is the meaning of a negative value N in the {active, N} option at gen_udp:open/2?

1 Like

Most likely it has the same meaning as for gen_tcp, which is explained here: Erlang -- inet

1 Like

So in gen_udp:open/2 that would mean the socket is opened in passive mode for any number =< 0, right?
I can’t find the source code dealing with this. Any idea?

1 Like

The way active, N mode works is different from “passive”.
Effectively, when you do {active, 5}, it means “deliver 5 data messages and then turn into passive”.

Supplying a negative number changes the current N. To give an example, if I did {active, 100} and then did {active, -50}, the result would be {active, 50}, meaning that only 50 data messages are delivered.

The code dealing with this parameter is located here: otp/inet_drv.c at master · erlang/otp · GitHub

It gets called through Erlang function inet:setopts/2 on a port that you use for your UDP socket.

Test case (and example of active, N behaviour) can be found here: otp/gen_udp_SUITE.erl at master · erlang/otp · GitHub

1 Like

I know how active and passive work, but was particularly interested in the situation where a socket is opened or set with {active, N =< 0}. As I understand it now, in this situation N is set to 0 and a “passive” message is sent to the owner on receipt of the next packet and the packet itself is not delivered to the owner as a message.

1 Like

Yes - the inet_drv code lines I referenced implement exactly this behaviour. But you’re right that it does not seem to be documented.

1 Like