[erlang-questions] gen_sctp:connect/5 change

[Serge Aleynikov]

It was implemented this way to make the returning signature of this 
function similar to gen_tcp:connect/3:

	{ok, Assoc} | {error, Reason}

Additionally, inet_sctp does additional analysis of the 
#sctp_assoc_change{} record to "filter out" false negative response 
(i.e. only #sctp_assoc_change{state=comm_up} is considered successful) 
and transform it to the {ok, ...} | {error, ...} form.  Note that {ok, 
#sctp_assoc_change{}} and {error, #sctp_assoc_change{}} are both valid 
responses.

If this error analysis is to be done by the user of gen_sctp, this 
wouldn't be quite obvious and may cause unnecessary confusion.

Finally, since this Assoc record is used in the gen_sctp:send/4 call, it 
was convenient to use it in this way for writing synchronous code:

	{ok, Assoc} = gen_sctp:connect(Sock, Host, Port, []),
	gen_sctp:send(Sock, Assoc, 0, <<"Test">>).

I also agree that having optional non-blocking connect in active mode 
would indeed come in handy.

Serge




Raimo Niskanen wrote:
> Hi list!
> 
> I am in the process of fixing active mode for gen_sctp, and up
> comes a question about why connect/5 returns {ok,Assoc} instead
> of just ok. The connect/5 code does an implicit recv/2 to get
> an #sctp_assoc_change{} message to return.
> 
> A change to connect/5 not returning the #sctp_assoc_change{}
> message, letting the user explicitly call recv/2 or in 
> active mode receive the #sctp_assoc_change{} would simplify
> the connect/5 code and perhaps make gen_sctp more SCTP.
> But would connect/5 become much less usable?
> 
> gen_sctp is still in beta state. If a change is appropriate,
> it should be made as soon as possible.
> 
> Nevertheless, these changes will not make it into R12B-2.
>