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

[Serge Aleynikov]

Raimo Niskanen wrote:
> On Wed, Apr 02, 2008 at 09:23:19PM -0400, Serge Aleynikov wrote:
> 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!).

I think logically it is not valid to use connect calls from the "server" 
side (for the reason you mentioned) even though SCTP doesn't prohibit 
this behavior there's no way to know whether the association change 
message is for the prior connection setup request or for some incoming 
"client" connection.  Therefore, it's better to use a separate SCTP 
socket for listening and a separate one(s) for initiating client 
connections to other SCTP servers to avoid this race.

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

Perhaps this analysis could be done in the driver code and split the 
result in two messages #sctp_assoc_up{} and #sctp_assoc_change{}?

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

Valid point.

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

The recommendation above on introducing #sctp_assoc_up{} would address 
this issue, but would "break" the existing 1-to-1 mapping of SCTP C 
structs to alike Erlang records.  The later may be a worthwhile sacrifice.

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

Agreed.

Regards,

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
>