Age | Commit message (Collapse) | Author |
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
|
|
Conflicts:
erts/preloaded/ebin/prim_inet.beam
lib/kernel/test/gen_sctp_SUITE.erl
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Test case for testing socket option {active, true} after
association is peeled off.
|
|
|
|
Also allow mixed address families to bind, since the first address on
a multihomed sctp socket must be bound with bind, while the rest are
to be bound using sctp_bindx.
At least Linux supports adding address of mixing families.
Make inet_set_faddress function available also when HAVE_SCTP is not
defined, since we use it to find an address for bind to be able to mix
ipv4 and ipv6 addresses.
|
|
Setting several ip addresses for an SCTP socket worked only for IPv4
on Linux. For IPv6 and for other for instance Solaris and FreeBSD, it
failed with badarg for both IPv4 and IPv6.
For the first address specified to gen_sctp:open, bind is now called,
while for any following addresses, sctp_bindx is called, repeatedly,
with one address at a time. Previously, sctp_bindx was called for all
addresses in one go, with the addresses in reverse order, and bind was
not called at all if more than one address was specified. Both
Solaris and FreeBSD requires bind to have been called before calling
sctp_bindx, and FreeBSD additionally allows at most one address at a
time in the call to sctp_bindx.
For some versions of Linux, for instance SuSE 10, the port can be 0
only for the call to bind but not for subsequent calls to sctp_bindx,
so replace with the port number assigned by the operating system.
|
|
|
|
inet:port/1 on peeled off socket returns 0. Bug? Who's?
|
|
It is better that gen_sctp:open/0-2 returns the informative Posix
return code {error,eprotonosupport} than previously {error,badarg}
when SCTP is not supported since it is so platform dependent.
|
|
|
|
The socket handler needs more flexibility regarding which events
are expected to be received.
|
|
|
|
|
|
|
|
Also fix tests for new prim_inet:open function.
|
|
raimo/sctp-getsetopts-dev/OTP-9544
Conflicts:
erts/emulator/drivers/common/inet_drv.c
lib/kernel/test/gen_sctp_SUITE.erl
|
|
Socket options 'sndbuf', 'recbuf' and 'linger were read from
the SCTP protocol layer instead of from the socket protocol layer.
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
* rani/sctp-sndrcvinfo/OTP-8795:
Fix xfer_active close expection for Solaris behaviour
Keep default #sctp_sndrcvinfo{} fields on gen_sctp:send/4
Fill in sinfo_assoc_id in struct sctp_sndrcvinfo for getopt()
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
|
|
|
|
inet:setopts(S, [{linger,{true,2}}]) returned {error,einval} for
SCTP sockets. The inet_drv had a bug when checking the option size.
|
|
* 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.
|
|
|