[erlang-questions] : gen_sctp:connect/5 change

[Raimo Niskanen]

On Wed, Apr 02, 2008 at 09:23:19PM -0400, Serge Aleynikov wrote:
> It was implemented this way to make the returning signature of this 
> function similar to gen_tcp:connect/3:
> 
> 	{ok, Assoc} | {error, Reason}

Ok, but making it similar to gen_tcp:connect/3 is not essential.

> 
> 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.
> 

And so is {error,econnrefused} with a subsequent
#sctp_assoc_change{state=comm_lost} received message.
(Solaris).

> 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.
> 

Valid point.

> 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">>).
> 

Yes, it is convenient.

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

No objection.



But..(speculating, not tested).. for the current gen_sctp:connect/5;
if an association comes in on a (passive) listen socket just while 
connect/5 is called - it internally calls recv/2 and may receive
the unrelated #sctp_assoc_change{} for another IP:Port,
and regard this as an internal error (it assumes the
first message has to be the one it is waiting for).
I do not know how to work around this bug, if it exists.
One ugly way would to return all received unrelated events
with the {ok,...} or {error,...} value (shrug!).

The code for active mode I have now does
receive {sctp,S,IP,Port,,..} if the socket is in active mode
so it is a selective receive, which would work better in this
scenario of competing incoming/outgoing #sctp_assoc_change{},
but this keeps the connect blocking. An option for non-blocking
connect is missing, or if the socket is active the connect
should be non-blocking and the caller should handle
the comm_up message...

And, if the user sets a too short timeout in connect/5 the
#sctp_assoc_change{state=comm_up} may arrive just after
the timeout. For passive mode this will not be noticed
until recv/2 is called (much) later. For active mode
the comm_up message arrives instantly in the inbox.
A well written caller would have to be ready for
these late messages anyway.

So, there are subtle semantic differences between 
connect/5 in passive vs active mode. And making connect/5
always non-blocking would remove the differences but
force the caller to handle the comm_up event the
right way... Which is the least bad alternative...?

Summary:
1) There is probably a problem with the current
   passive connect/5 that may be solved by making
   it non-blocking but that will be unconvenient.
   There might be other ways to solve that problem
   and maybe ther is no problem.
2) Should connect/5 for active socket be non-blocking
   or not, or selectable. If connect/5 for passive
   socket is made non-blocking it should be the
   same for active socket.



> 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.
> > 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB