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

[Serge Aleynikov]

Raimo Niskanen wrote:
> Very true but, if it is allowed by SCTP someone will want to do it.
> Maybe we can just disallow connect on a listen socket and
> call it a known limitation.

Possibly.

>>> 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{}?
> 
> Sorry, you will have to elaborate. What should be analyzed
> and what should be split?

I meant to have a check in the driver for 
#sctp_assoc_change{state=comm_up} message and
turn this record to #sctp_assoc_up{} with the same field names/values as
#sctp_assoc_change{} leaving the later to represent all other states but
comm_up.

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

Please let me know if the statement above is still unclear.

Serge