ERL-1468: "Protocol not supported" error for udp with socket:open/3

[OTP-Maintainer]

Original reporter: JIRAUSER17202
Affected version: Not Specified
Component: Not Specified
Migrated from: https://bugs.erlang.org/browse/ERL-1468

---

Hi, 

 

getting this error with socket:open/3 while with open/2 everything is fine. At least, such behaviour is not expected when following reference [http://erlang.org/doc/man/socket.html#open-3] & [http://erlang.org/doc/man/socket.html#type-protocol] 

 

{{1> \{ok, Socket} = socket:open(local, dgram).}}

{{{ok,\{'$socket',#Ref<0.745231699.1157758979.206191>}}}}

 

 

{{2> \{ok, Socket} = socket:open(local, dgram, udp).}}

{{** exception error: no match of right hand side value \{error,eprotonosupport}}}

 

Bests,

Roman

 

 

 

[OTP-Maintainer]

raimo said:

On the contrary; the documentation explains that that combination does not work.
{quote}For some types there is a default protocol, indicated by default, which it *may* be possible to specify. And for Domain = local, if a protocol *is* pecified, it *must* be default.
{quote}
It *may* be possible to specify a protocol, meaning that it also *may not* be possible to specify, meaning that for some protocol domains you *must not* specify the protocol, meaning that for some protocol domains you *must* use the *default* protocol.

So, for address family {{AF_LOCAL}}, specified by you with {{Domain = local}}, there is no protocol {{udp}}, but there is a very similar default, unnamed, protocol of type {{dgram}}.

We have no explanation as to why, but for all Unix-like platforms we have seen; the {{Domain = local, Type = dgram}} protocol has no name and can only be selected by asking the platform for the default protocol.

[OTP-Maintainer]

JIRAUSER17202 said:

Hi Raimo, 

 

thank you very much for clarification. So arguments' behaviour mimics empirics of system calls.

Indeed, after spending extra time, reading whole documentation, and -multiple- several trials-and-errors developer might infer this even when one tiny function is needed only.

 

As a suggestion, adding explicit examples to the documentation for major combinations would be so helpful. 

 

Bests,

Roman 

 

[OTP-Maintainer]

raimo said:

We try hard to not mimic as in trying to do the same as the platform, except in some cases where we hide small differences between platforms (not applicable in this case).

The result from {{socket:open(local, dgram, udp)}} is merely the result of the libc call {{socket(PF_LOCAL, SOCK_DGRAM, protocol)}} where {{protocol}} comes from {{getprotobyname("udp")}}. The return value {{EPROTONOSUPPORT}} is translated into {{{error,eprotonosupport}}}.

I do not get what you mean with "even when one tiny function is needed only".

The problem with an example of this is that it will document what should be documented by the platform.  And that may change in the future making our example incorrect.  The Linux documentation for socket(2) states that {{EPROTONOSUPPORT}} means "The protocol type or the specified protocol is not supported within this domain.", and unix(7) states that "unix_socket = socket(AF_UNIX, type, 0);"  where 0 means the default protocol, as documented in socket(2).

So the platform documentation, I think, is also pretty clear about this, once you find it, which I guess unfortunately is harder than might be expected...

But if a particular example is common enough, I agree it is worth adding to our documentation, despite the (in this case very small) risk of becoming incorrect one day.

The documentation in the master branch (upcoming OTP 24.0) already has got stronger pointers to the platform documentation, and I will see if I can clarify it further...

[OTP-Maintainer]

JIRAUSER17202 said:

Raimo, 

Indeed, this is the point:

> once you find it, which I guess unfortunately is harder than might be expected

Great that it might be improved in OTP 24 docs! Maybe not to risk generality of the reference, [https://www.erlang.org/course/] or similar could be a better fit for snippets. 

 

Everything is clear now. Thank you so much for taking time to provide detailed explanation

 

Bests,

Roman