| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
Language cleaned up by technical writers from Combitech.
Proofreading and corrections by Björn Gustavsson and
Hans Bolinder.
|
|
|
|
Fix mistakes found by 'xmllint'.
|
|
|
|
Handle peer addresses that are unconfirmed (i.e. in state SCTP_UNCONFIRMED).
Handle unknown states instead of using ASSERT
|
|
|
|
'one-to-may' should be 'one-to-many'
|
|
Add the {active,N} socket option, where N is an integer in the range
-32768..32767, to allow a caller to specify the number of data messages to
be delivered to the controlling process. Once the socket's delivered
message count either reaches 0 or is explicitly set to 0 with
inet:setopts/2 or by including {active,0} as an option when the socket is
created, the socket transitions to passive ({active, false}) mode and the
socket's controlling process receives a message to inform it of the
transition. TCP sockets receive {tcp_passive,Socket}, UDP sockets receive
{udp_passive,Socket} and SCTP sockets receive {sctp_passive,Socket}.
The socket's delivered message counter defaults to 0, but it can be set
using {active,N} via any gen_tcp, gen_udp, or gen_sctp function that takes
socket options as arguments, or via inet:setopts/2. New N values are added
to the socket's current counter value, and negative numbers can be used to
reduce the counter value. Specifying a number that would cause the socket's
counter value to go above 32767 causes an einval error. If a negative
number is specified such that the counter value would become negative, the
socket's counter value is set to 0 and the socket transitions to passive
mode. If the counter value is already 0 and inet:setopts(Socket,
[{active,0}]) is specified, the counter value remains at 0 but the
appropriate passive mode transition message is generated for the socket.
This commit contains a modified preloaded prim_inet.beam due to changes in
prim_inet.erl.
Add tests for {active,N} mode for TCP, UDP, and SCTP sockets.
Add documentation for {active,N} mode for inet, gen_tcp, gen_udp, and
gen_sctp.
|
|
|
|
|
|
|
|
|
|
|
|
* UDP: ulticast_if, multicast_loop and multicast_ttl,
add_membership and drop_membership
* Inet: bit8, buffer, deliver, high_watermark, linger and
low_watermark
|
|
|
|
|
|
|
|
|
|
Running Dialyzer on the test suites revealed a few type errors.
|
|
|
|
|
|
|
|
|
|
* 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.)
|
|
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.
|
|
|
