Re: Finishing 'socket'

I think we will have to fix gen_sctp to handle this somehow,
but we have not managed to prioritize it yet...

/ Raimo



On Tue, Oct 20, 2020 at 02:09:10PM +0300, Svilen Ivanov wrote:
> Hi,
> 
> Will SCTP support be ready for the 24.0 release?
> Currently gen_sctp is broken for Linux kernels >= 5.5 (
> https://bugs.erlang.org/browse/ERL-1176) and it will be great to have
> some means to use SCTP these kernels.
> 
> Best regards,
> Svilen Ivanov
> 
> On Tue, 2020-10-20 at 11:24 +0200, Raimo Niskanen wrote:
> > Hello List!
> > 
> > I have committed changes for 'socket' to the master branch.
> > These were most of the "big" changes for the 24.0 release,
> > so feedback is now most welcome!
> > 
> > From the Release Notes to come:
> > 
> >     The experimental new socket API has been further developed. Some
> >     backwards incompatible changes with respect to OTP 23
> >     has been made.
> > 
> >     The control message format has been changed so a decoded value
> >     is now in the 'value' field instead of in the 'data' field.
> >     The 'data' field now always contains binary data.
> > 
> >     Some type names have been changed regarding message headers and
> >     control message headers.
> > 
> >     socket:bind/2 now returns plain ok instead of {ok, Port} which
> > was
> >     only relevant for the inet and inet6 address families and often
> >     not interesting.  To find out which port was chosen port use
> >     socket:sockname/1, when needed.
> > 
> > There might be more changes I have missed to note.  If you find
> > any please let me know so I can add them to the Release Notes.
> > 
> > We have thoughts about more creative error returns, such as instead
> > of    {error, {invalid, {msg, Msg, addr}}}
> > maybe {error, [invalid, msg, addr, Addr]},
> > or    {error, {invalid, [msg, addr, Addr]}}.
> > Maps variants have also been suggested, but I can have not found
> > a nice format.
> > 
> > Best regards

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB