aboutsummaryrefslogtreecommitdiffstats
path: root/lib/kernel/src/gen_sctp.erl
AgeCommit message (Collapse)Author
2012-02-04Fix port leaking after controlling_process(Port, self())Ricardo
Add case to handle the situation when someone call {gen_tcp,gen_udp}:controlling_process(Port, self()). Also improve spec and doc from gen_udp and gen_sctp for controlling_process/2. To reproduce the issue, open an UDP port: 4> {ok,Port} = gen_udp:open(9000, [binary]). {ok,#Port<0.587>} 5> gen_udp:controlling_process(Port, self()). ok Simulate error: 6> 1=2. ** exception error: no match of right hand side value 2 Here is the leak: 7> inet:i(). Port Module Recv Sent Owner Local Address Foreign Address State Type 581 inet_udp 0 0 <0.31.0> *:cslistener *:* BOUND DGRAM ok
2012-01-23Correct two contracts in gen_sctp.erlHans Bolinder
binary should be binary().
2011-11-17erts,kernel: Implement gen_sctp:peeloff/2Raimo Niskanen
2011-11-17erts,kernel: Add type stream sockets to SCTPRaimo Niskanen
2011-08-31Improve and correct types and specifications in Kernel and STDLIBHans Bolinder
Running Dialyzer on the test suites revealed a few type errors.
2011-08-25Improve types and specifications of the inet modulesHans Bolinder
2011-05-09Types and specifications have been modified and addedHans Bolinder
2010-09-06Let an 8-tuple given as ip_address() for gen_tcp/gen_udp/gen_sctp imply 'inet6'Per Hedeland
Currently an 8-tuple representing an IPv6 address is not accepted by gen_tcp:listen/2, gen_tcp:connect/3,4, gen_udp:open/2, or gen_sctp:open/1,2, unless the 'inet6' option is also given. This means that an application that has obtained the address, e.g. from configuration that allows for either IPv4 or IPv6, must always check the type of the address before passing it to these functions. Letting the functions infer 'inet6' from the 8-tuple, in case other options do not override this choice, improves usability.
2010-08-31Keep default #sctp_sndrcvinfo{} fields on gen_sctp:send/4Raimo Niskanen
2010-02-08Merge branch 'sc/sctp-connect-nowait' into ccase/r13b04_devErlang/OTP
* sc/sctp-connect-nowait: Implement a non-blocking SCTP connect OTP-8414 There are new gen_sctp:connect_init/* functions that initiate an SCTP connection without blocking for the result. The result is delivered asynchronously as an sctp_assoc_change event. (Thanks to Simon Cornish.)
2010-02-06Implement a non-blocking SCTP connectSimon Cornish
This patch adds a new set of functions - gen_sctp:connect_init/* that initiate an SCTP connection without blocking for the result. The result is delivered asynchronously as an sctp_assoc_change event. The new functions have the same API as documented for gen_sctp:connect/* with the following exceptions: * Timeout is only used to supervise resolving Addr (the peer address) * The possible return values are ok | {error, posix()} The caller application is responsible for receiving the #sctp_assoc_change{} event and correctly determining the connect it originated from (for example, by examining the remote host and/or port). The application should have at least {active, once} or use gen_sctp:recv to retrieve the connect result. The implementation of gen_sctp:connect suffers from a number of shortcomings which the user may avoid by using gen_sctp:connect_init and adding code to receive the connect result. First, irrespective of the Timeout value given to gen_sctp:connect, the OS attempts and retries the SCTP INIT according to various kernel parameters. If the Timeout value is shorter than the entire attempt then the application will still receive an sctp_assoc_change event after the {error, timeout} is returned from the initial call. This could be somewhat confusing (either to the application or the designer!) especially if the status is comm_up. Subsequent calls to connect before the OS has finished this process return {error, ealready} which may also be counter-intuitive. Second, there is a race-condition (documented in comments in inet_sctp.erl) that can cause the wrong sctp_assoc_change record to be returned to an application calling gen_sctp:connect. The race seriously affects connection attempts when using one-to-many sockets.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP